computer-implemented method to establish point-to-point ("p2p") communication between mobile

专利摘要:
APPARATUS AND METHOD FOR COMPATIBILIZING USERS BY ONLINE SESSIONS. The present invention relates to a machine-readable device, method and medium which are described for establishing point-to-point communication channels ("P2P"). In particular, in one modality, an intermediary service performs a series of operations to meet compatibility requests received from a group of mobile devices. In one mode, the intermediation service groups compatibility requests into compatible sets based on the application for which the requests are received and one or more variables associated with the application. Compatibility requests within each compatibility set can then be made compatible based on variables, such as the type of NAT, type of connection and language associated with each of the mobile devices. Other variables, such as geographic position, level of experience, and age of compatibility requests can also be used to make compatibility decisions.
公开号:BR112012025586B1
申请号:R112012025586-0
申请日:2010-09-23
公开日:2021-02-09
发明作者:Jeremy Matthew Werner；Philip Smith；Andrew H. Vyrros；Patrick Gates
申请人:Apple Inc.；
IPC主号:

专利说明:

BACKGROUND Priority Claim
[0001] This patent application claims priority over U.S. Provisional Patent Application No. 12 / 321,842, filed on April 7, 2010 entitled "Apparatus and Method For Matching Users For Online Sessions".
[0002] The invention to be described and claimed in this patent application was prematurely and without authorization from Apple described to the public when an Apple iPhone 4 prototype was apparently stolen from an Apple engineer on March 25, 2010. The application for US priority patent, on which this patent application is based, was not filed before the apparent theft. Field of the Invention
[0003] This invention generally relates to the connection field in computer networks. More particularly, the invention relates to an improved device and method for making users of computing devices, such as mobile devices, compatible for online communication sessions (e.g., point-to-point sessions). Related Technique Description A. Network Address Translation ("NAT")
[0004] Large public networks, such as the Internet, often have connections to smaller private networks, such as those maintained by a corporation, Internet service provider, or even individual homes. By their very nature, public networks must be commonly combined in the allocation of network addresses, that is, public addresses. For a variety of reasons, private network providers often decide to use private network addresses for private networks that are not part of the commonly agreed allocation. Thus, for network traffic from the private network to be able to traverse the public network, some form of private / public network address translation ("NAT") is required.
[0005] A device that performs NAT operations changes the data packets that are sent outside the private network to comply with the addressing scheme of the public network. In particular, the network address translator replaces the original private address and port number of a package with its own public address and a designated port. A network address translator also changes the data packets that are received for computers on the private network to replace the destination public address and port number with the correct private address and port number of the desired recipient. As used in this application, the term address should be interpreted to include both an address and a port number if appropriate in the context, as would be understood by one of ordinary skill in the art.
[0006] NAT has become increasingly common in modern network computing. An advantage of NAT is that it reduces the depletion of the address space of the public network. For example, TCP / IP addressing, which is used on the Internet, comprises four series of three digits each, thereby providing a finite address space. In addition, certain portions of this address space are reserved for particular uses or users, further depleting the actual number of addresses available. However, if NAT is used, a private network or subnet can use an arbitrary number of addresses, and still present only a simple, standardized public address to the outside world. This makes the number of available addresses practically unlimited, because each private network can theoretically use exactly the same private addresses.
[0007] An advantage provided by NAT is the increased security that results from the fact that those on the public network cannot determine the real (ie, private) network address of a computer on a private network. This is because only the public address is provided on the public network by the network address translator. In addition, this public address can correspond to any number of computers on the private network.
[0008] Different types of NAT employ different levels of security. For example, with a "full cone NAT", where an internal address (iAddr: iPort) is mapped to an external address (eAddr: ePort), any external host can send packets to iAddr: iPort by sending packets to eAddr: ePort. With a "restricted cone NAT", an external host with an hAddr address can send packets to iAddr: iPort by sending packets to eAddr: ePort only if iAddr: iPort had previously sent a packet to hAddr. The external host's door is irrelevant. With a "Port Restricted Cone NAT", an external host that has an hAddr: hPort address / port can send packets to iAddr: iPort by sending packets to eAddr: ePort only if iAddr: iPort previously sent a packet to hAddr: hPort. Finally, with Symmetric NAT, each request from the same iAddr: iPort to a specific destination IP address and port is mapped to a single eAddr: ePort. If the same internal host sends a packet to a different destination, a different external address and port mapping is used. Only an external host that receives a packet from an internal host can send a packet back to the internal host. B. NAT releases with Peer-to-Peer networks
[0009] Point-to-point computing ("P2P") refers to a distributed network architecture comprised of computational nodes that makes a portion of its resources directly available to other network participants. The points in a P2P network establish direct communication channels with each other and act as both clients and servers, in contrast to the traditional client-server model in which servers provide resources and clients consume resources.
[00010] The NAT operations described above pose numerous problems for P2P connections. For example, establishing a direct connection between two pairs becomes increasingly difficult if one or both pairs are located behind one or more of the types of NAT described above. This problem is exacerbated by the fact that mobile devices, such as the Apple iPod Touch®, Apple iPhone®, Apple iPad® and several other devices (for example, RIM Blackberry® devices, Palm Pre® devices, etc.) are frequently moved between networks having different NAT implementations. For example, the Apple iPhone® is capable of communicating over Wi-Fi networks (for example, 802.11b, g, n networks); 3G networks (for example, networks of the Universal Mobile Telecommunications System ("UMTS"), High Speed Data Packet Access networks ("HSUPA"), etc.); and Bluetooth networks (known as personal area networks ("PAN’s")). Future mobile devices will be able to communicate on additional communication channels, such as WiMAX, Advanced International Mobile Telecommunication ("IMT"), and Advanced Long Term Evolution ("LTE"), to name a few. SUMMARY
[00011] A machine-readable device, method, and medium are described to establish point-to-point communication channels ("P2P"). In particular, in one modality, an intermediary service performs a series of operations to meet compatibility requests received from a group of mobile devices. In one embodiment, the intermediation service groups compatibility requests into compatible sets based on the application for which the requests are received and one or more variables associated with the application. Compatibility requests within each compatibility set can then be combined based on variables, such as the type of NAT, type of connection and language associated with each of the mobile devices. Other variables, such as geographic position, level of experience, and age of compatibility requests can also be used to make combination decisions. BRIEF DESCRIPTION OF THE DRAWINGS
[00012] A better understanding of the present invention can be obtained from the following detailed description together with the following drawings, in which:
[00013] Figure 1 illustrates a network architecture in which a group of mobile devices and services communicate over a network.
[00014] FIGS. 2a-c illustrate transactions between a modality of a connection data exchange service (CDX), an intermediary service and / or an invitation service.
[00015] Figure 3 illustrates a modality of an input data structure.
[00016] Figure 4 illustrates a modality of a method implemented by a CDX service.
[00017] Figure 5 illustrates a modality of a method implemented by a mobile device.
[00018] Figure 6 illustrates a group of mobile devices connected by primary and secondary communication channels.
[00019] Figure 7 illustrates a modality of a mobile device to select between primary and secondary communication channels.
[00020] Figures 8a-b illustrate a group of mobile devices connected by primary and secondary communication channels and the resulting network topology.
[00021] Figure 9 illustrates a modality of a method implemented by computer to select between primary and secondary communication channels.
[00022] Figure 10 illustrates a network architecture in which a group of mobile devices and services, including a directive service and a push notification service, communicate over a network.
[00023] Figure 11 illustrates transactions between an invitation service, a push notification service and a connection data exchange service (CDX).
[00024] Figure 12 illustrates transactions between a modality of an invitation service, a push notification service, and a repetition service.
[00025] Figure 13 illustrates a modality of a repetition service to establish a repetition connection between two or more mobile devices.
[00026] Figure 14 illustrates a modality of a NAT compatibility diagram to determine NAT compatibility.
[00027] Figure 15 illustrates a modality of an intermediary service to combine with mobile devices for online applications.
[00028] Figure 16 illustrates a modality of a method for compatibility of users / devices.
[00029] Figures 17a-d illustrate an exemplary series of table updates made to match users / devices.
[00030] Figure 18 illustrates a method for making users / devices compatible using different compatibility adjustment variables.
[00031] Figure 19 illustrates an architecture that displays an application programming interface (API) for applications and an API service for communicating with the group of services.
[00032] Figure 20 illustrates a modality of a game architecture with an application API, a game background program and a game services module for communicating with services.
[00033] Figure 21 illustrates a modality of an API implementation program component and an API calling program component.
[00034] Figure 22 illustrates a modality in which API calls are made between operating systems, services and applications.
[00035] Figure 23 illustrates a modality of an exemplary computer system architecture.
[00036] Figure 24 illustrates another modality of an exemplary computer system architecture. DETAILED DESCRIPTION OF PREFERENTIAL MODALITIES
[00037] Described below are modalities of a device, method, and machine-readable medium for establishing, maintaining and using primary and / or backup ("P2P") point-to-point communication channels on a network. An invitation service and an intermediary service are also described for guest users and users with compatibility, respectively, for P2P sessions. In addition, a retry service is described to allow users to establish repeat connections under certain specified conditions. Finally, an applied architecture and the associated application programming interface (API) are described to allow application developers to design applications that take advantage of the various collaborative online attributes described in this application.
[00038] Throughout the specification, for the sake of explanation, numerous specific details are presented in order to provide a complete understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without some of these specific details. In other examples, well-known structures and devices are not shown or are shown in a block diagram form to avoid obscuring the underlying principles of the present invention. Apparatus and Method for Efficient and Secure Connection Data Exchange
[00039] As illustrated in figure 1, a general network topology implemented in an embodiment of the invention can include a group of mobile computing devices "client" or "point" AD, 120-123, respectively, communicating with each other and with a or more services 110-112 on a network 120. Although illustrated as a single network cloud in Figure 1, "network" 120 can include a variety of different components including public networks, such as the Internet and private networks, such as Wi-Fi networks -Fi local (for example, wireless 802.11 home networks or wireless points), local area Ethernet networks, cellular data networks (for example, 3G, Edge, etc.), and WiMAX networks, to name a few. For example, the mobile device A 120 can be connected to a home Wi-Fi network represented by the network connection 125, mobile device B 121 can be connected to a 3G network (for example, Universal Mobile Telecommunications System ("UMTS") , High Speed Data Packet Access ("HSUPA"), etc.) represented by network connection 126, the mobile device C 122 can be connected to a WiMAX network represented by network connection 127, and the mobile device 123 can be connected to a public Wi-Fi network represented by network connection 128. Each of the local network connects to 125-128 to which mobile devices 120-123 are connected can be connected to a public network, such as as the Internet through a NAT port and / or device (not shown in figure 1), thereby allowing communication between multiple 120-123 mobile devices on the public network. However, if two mobile devices are on the same local or private network (for example, the same Wi-Fi network), then the two devices can communicate directly on that local / private network, bypassing the public network. It should be noted, of course, that the underlying principles of the invention are not limited to any particular set of network types or network topology.
[00040] Each of the mobile devices 120-123 illustrated in figure 1 can communicate with a connection data exchange service (CDX) 110, an intermediary service 111, and an invitation service 112. In one embodiment, the 110-112 services can be implemented as a program that runs through one or more physical computing devices, such as servers. As shown in figure 1, in a modality, services 110-112 can be implemented within the context of a larger data service 100 managed by the same entity (for example, the same data service provider) and accessible by each of the mobile devices 120-123 on network 120. Data service 100 may include a local area network (for example, an Ethernet-based local network) connecting various types of servers and databases. Data service 100 may also include one or more storage area networks ("SANs") to store data. In one embodiment, databases store and manage data related to each of the 120-123 mobile devices and the users of those devices (for example, user account data, device account data, user application data, etc. .).
[00041] In one modality, the intermediation service 111 can match two or more mobile devices in a collaborative P2P session based on a specified set of conditions. For example, users of two or more mobile devices may be interested in playing a particular multiplayer game. In such a case, the intermediation service 111 can identify a group of mobile devices to participate in the game based on variables, such as the skill level of each user, the age of each user, the timing of compatibility requests. , the particular game for which a combination is requested and several game-specific variables. By way of example, and not limitation, the intermediation service 111 may attempt to match users with similar levels of expertise in the game of a particular game. Additionally, adults can be made compatible with other adults and children can be made compatible with other children. In addition, the brokerage service 111 can prioritize user requests based on the order in which those requests are received. The underlying principles of the invention are not limited to any particular set of criteria compatibility or any particular type of P2P application.
[00042] As described in detail below, in response to a compatibility request, the intermediation service 111 can coordinate with the CDX 110 service to ensure that all compatible participants receive the connection data necessary to establish P2P sessions in an efficient and safe.
[00043] In one modality, the invitation service 112 also identifies mobile devices for participation in collaborative P2P sessions. However, in the case of invitation service 112, at least one of the participants is specifically identified by another participant. For example, the mobile device user A 120 can specifically request a collaborative session with the mobile device user B 121 (for example, identifying mobile device B with a user ID or phone number). As with the intermediation service 111, in response to an invitation request, the invitation service 112 can identify the set of participants and coordinates with the CDX 110 service to ensure that all participants receive the connection data necessary to establish P2P sessions in an efficient and safe way.
[00044] As mentioned above, in one modality, the CDX 110 service operates as a central point of exchange of connection data necessary to establish P2P sessions between two or more mobile devices. Specifically, a modality of the CDX service generates NAT traversal data (sometimes referred to as "Hole Punch data") in response to requests from the mobile device to allow external services and clients to communicate via NAT from each mobile device (ie , use "hole punch" by NAT to reach the device). For example, in one mode, the CDX service detects the external IP address and the port required to communicate with the mobile device and provides this information to the mobile device. In one embodiment, the CDX service also receives and processes lists of mobile devices generated by the intermediation service 111 and invitation service 112 and efficiently and securely distributes connection data to each of the mobile devices included in the lists (as described in detail below) .
[00045] In one embodiment, communication between mobile devices and the CDX 110 service is established using a relatively light network protocol, such as User Datagram Protocol ("UDP") sockets. As is known to those skilled in the art, UDP socket connections do not require authentication dialogs to guarantee packet reliability, ordering, or data integrity, and therefore do not consume as much overhead packet processing as socket connections. TCP. Consequently, the lightweight, stateless nature of UDP is useful for servers that respond to small queries from a vast number of clients. In addition, unlike TCP, UDP supports packet transmission (in which packets are sent to all devices on a local network) and multistreaming (in which packets are sent to a subset of devices on the local network). As described below, although UDP can be used, security can be maintained on the CDX 110 service by encrypting the NAT traversal keys using session data.
[00046] In contrast to the low overhead, lightweight network protocol used by the CDX 110 service, in a modality, communication between mobile devices 120-123 and the intermediation service 111 and / or invitation service 112 is established with an inherently secure network protocol, such as Secure Hypertext Transfer Protocol ("HTTPS"), which depends on Secure Sockets Layer ("SSL") or Transport Layer Security ("TLS") connections. The details associated with these protocols are well known to those skilled in the art.
[00047] Figure 2a illustrates an exemplary series of transactions that can be implemented by a CDX server. When describing the operation of a modality of the CDX service, the following terms must have the following meanings:
[00048] Connection Data - That is, the information that potential pairs need to exchange with each other to establish the Point to Point Session. Described below are modalities of a mechanism by which this information can be exchanged.
[00049] CDX Server - a CDX Server in a modality is an authenticated multiform reflector that allows authorized entities to exchange arbitrary data. These data are referred to as Payload.
[00050] CDX Session - a CDX Session refers to a group of client devices that can communicate with each other through the CDX Server. Each client device that is a part of the session is called a CDX Entry. Each session has a CDX Unique Session ID, which is a large integer that can be used to identify or refer to an individual session.
[00051] CDX Request - a request that is sent from a client device to the CDX Server. An order usually consists of two parts: a CDX Entry and Payload. In this mode, the payload is Connection Data encrypted with the Session Key.
[00052] CDX Response - a CDX Response consists of what is "reflected" back to other devices in a CDX Session when the CDX Server receives a CDX Request from a member of the CDX Session. It is built by adding Payload to the CDX Input Checker of the CDX Input used in the given CDX Order.
[00053] CDX Entry - a CDX Entry tells the CDX Server how to send a Payload to members of the CDX Session. In one mode, it is "signed" with the CDX Entry Key to prevent tampering or tampering. As illustrated in figure 3, in one embodiment, a CDX Entry contains the following information:
[00054] Session ID301 that is not encrypted or cloaked in a modality.
[00055] The number of participants 302 in the session that is not encrypted or disguised in a modality.
[00056] The index 303 of which participant in the session to which this entry refers (not encrypted or camouflaged in a modality).
[00057] A 304 expiration time / date, after which the entry is considered invalid (not encrypted or camouflaged in a modality).
[00058] The Hole Punch CDX Data 305-306 for each participant in the session, encrypted using the CDX Entry Key in one mode.
[00059] The Message Authentication Code 307 using the CDX Entry Key, which acts as a "Digital Signature" to ensure that the entry is authentic.
[00060] CDX Entry Verifier - the first part of a CDX Entry, minus the Hole Punch CDX Data and the Message Authentication Code.
[00061] Payload - This is the second part of a CDX Request and a CDX Response. The payload is the data that a client device wants to communicate to other devices in the CDX Session. In this mode, the payload is the Connection Data encrypted with the Session Key. The CDX Server does not decipher the payload, in one mode, it simply passes along it unchanged.
[00062] Session Key - This is the key used by clients to encrypt the Connection Data. In one embodiment, this key is not known by the CDX server. In this modality, the Session Key is generated by the intermediation service and transmitted to customers along with their individual CDX Entries.
[00063] CDX Entry Key - This is the key used to create and "sign" CDX Entries. The CDX Entry Key is known only to the CDX Server and the service that generates CDX Entries - which, as described below, can be the intermediation service and / or invitation service.
[00064] Hole Punch CDX Request - special type of CDX Request that is used to obtain the Hole Punch CDX Data from the CDX Server.
[00065] Hole Punch CDX data - This is a large volume of data (blob) that describes how the CDX Server can send the information to the client that originally requested it. It is obtained by submitting a Hole Punch CDX Request to the CDX Server. CDX Hole Punch Data must be collected from each client device in the CDX Session before CDX Entries can be generated. Hole Punch CDX data ("sometimes referred to as NAT traversal data") can include the public IP address and port of a requesting device.
[00066] Moving now to figure 2a, in a modality, the mobile device A 120 and the mobile device B 121 can carry out a collaborative application, such as a multiplayer game or a collaborative conversation session that requires a P2P connection with a or more computing devices. At 201a, the A 120 mobile device transmits a Hole Punch CDX Request to the CDX 110 Server. The CDX 110 Server then responds with the Hole Punch CDX Data at 202a. In one embodiment, the Hole Punch data includes the public IP address and port of the mobile device A and / or any other data needed to pass through a Hole Punch through the NAT of the mobile device A (for example, NAT type data that define the type of NAT of the mobile device A). Similar transactions are performed for mobile device B at 201b and 202b, respectively.
[00067] At 203a and 203b, mobile devices A and B then send compatibility requests including the Hole Punch CDX Data to the Intermediation Service, along with any additional matching criteria (described below). At this stage, mobile devices A and B can begin to build the Connection Data needed to establish a P2P connection. This can be accomplished, for example, using a transaction, such as a standard Internet Connectivity Establishment ("ICE") transaction (for example, by NAT traversal service). However, the underlying principles of the invention are not limited to any particular mechanism for determining the connection data.
[00068] In one modality, once the intermediation service 111 found the group of client devices with matching criteria, it can generate a CDXunique Session ID, a CDXunica Entry for each member of the CDX Session, and a Session Key only. In one embodiment, the 111 intermediation service can encrypt the Hole Punch CDX Data from the CDX entry using a CDX unique entry key. In 204a and 204b, the brokerage service can then send each of the mobile devices A and B its CDX Entry and Session Key.
[00069] Mobile device A receives the Session Key and CDX Entry and encrypts its Connection Data previously determined using the Session Key, making a Payload. In one embodiment, mobile device A builds a CDX Order by adding the Payload built to the CDX Entry. At 205a, mobile device A sends the CDX Request to the CDX Server 110. Mobile device B could also perform the same operations and transmit a request to the CDX server at 205b.
[00070] In 206a, CDX Server 110 receives the CDX Request, examines the entry to ensure that it is valid and authentic (for example, based on the message authentication code 307). If the CDX Entry is invalid, the order is abandoned. In one embodiment, the CDX Server then decrypts the Hole Punch CDX data set that is contained in the CDX Entry using the CDX entry key. In one embodiment, the CDX entry key can include an expiration time / date that can also be transmitted with the entries. The CDX 110 service and 111 intermediary service can store two (or more) CDX input keys other than encryption / decryption - a first that is currently active and a second that will be active to reach the expiration time / date of the first. To receive an entry, the CDX 110 service can read the expiration time / date to determine which entry key to use. When a CDX entry key expires, both CDX service 110 and broker service 111 can each generate a new entry key (which will be the next key to be used after the current entry key expires). In one embodiment, the CDX 110 service and the intermediation service 111 execute the same key generating algorithm to ensure consistency with the two input keys. For example, techniques, such as those used for the well-known RSA SecurID authentication mechanism, can be used in which a new authentication code is generated at fixed intervals. In one mode, a new CDX entry key is generated on a daily basis. However, the underlying principles of the invention are not limited to any particular mechanism for generating CDX input keys.
[00071] The same operations can be performed as shown in 206b for the mobile device B. The CDX Server builds a CDX Response from the CDX Request and then uses the CDX Hole Punch Data to send the CDX Response to participants in the CDX Session (sent to mobile device B at 207a and mobile device A at 207b).
[00072] Mobile device B receives CDX Response 207a from CDX Server. Client Device B examines the CDX Entry Verifier to ensure that the Session ID matches the Session ID of its own CDX Entry. Mobile device B can then decrypt the Payload using the Session Key, producing Connection Data from Mobile device A. Mobile device B then uses Connection Data from mobile device A to begin the process to establish the P2P session. In one embodiment, these involve standard ICE transactions. However, the underlying principles of the invention are not limited to any particular mechanism for establishing P2P communication.
[00073] As mentioned above, in one embodiment, mobile device A and B establish Secure Hypertext Transfer Protocol ("HTTPS") sessions to communicate with the 111 intermediary service (for example, using order transactions / response) and establish UDP sockets to communicate with the CDX service. Compatibility requests 204a, 204b may include NAT type and Hole Punch data (for example, the public IP address and port) previously determined for each respective mobile device. In a modality that involves a multiplayer game, each compatibility request can identify the player on each mobile device (for example, using an individual player ID code), the game that each user wants to play, the number of players to participate in the game , and / or other game configuration variables associated with the desired game. By way of example, and not limitation, the game configuration variables associated with a game can include a level of difficulty (for example, easy, normal, difficult), a user's age (for example, "under 13 years old "), a sub-region of the game (for example," level 2 "), and / or a player skill level (for example, expert, beginner, intermediate). As described in detail below, these variables are sometimes referred to as a game "bucket" and are identified using a unique "bucket ID". Each game can include different sets of bucket ID’s to identify different game setup variables.
[00074] In one embodiment, mobile device B sends and acknowledges at 208a and 209a. Similarly, recognition from mobile device A is transmitted at 208b and 209b. If acknowledgments from mobile device A or B are not received after a specified period of time, then connection data 207a can be forwarded to mobile device B 212. Any CDX 110 service can initiate the retry and / or mobile device A 120 you can start the retry.
[00075] Figure 2b illustrates a more detailed example in which three different mobile devices 120-122 negotiate for P2P connections using the CDX service and intermediation service 111. Figure 2b also illustrates two additional services used by mobile devices 120-122 for establish a connection: NAT 291 traversal service to determine NAT type and NAT 290 traversal service to determine complete connection data for each mobile device (for example, using an ICE connection data transaction). It should be noted, however, that the separate services must not comply with the underlying principles of the invention. For example, in an alternative modality, NAT traversal functions performed by each of these 290-291 services can be integrated directly within the CDX 110 service and / or intermediation service 111. Similarly, the functions performed by both service traversal services NAT 290-291 can be integrated within the single NAT traversal services. In summary, the specific functional separation shown in figure 2b is not necessary to comply with the underlying principles of the invention.
[00076] Moving now to the specific details of figure 2b, in 220, mobile device A transmits a NAT type request to the NAT 291 traversal service. In response, the NAT 291 traversal service can use several known techniques including implementing a series of transactions to determine the type of NAT used by the mobile device A. For example, the NAT 291 traversal service may attempt to open different IP addresses and ports in NAT from mobile device A and communicate with mobile device A through those ports using different IP / port compatibility. In this way, the NAT employed by the mobile device A can be classified as one of the types of NAT described above (for example, full cone, restricted cone, cone restricted by port, symmetric) or an alternative type of NAT. This information can then be provided to the mobile device A 120 as illustrated.
[00077] At 221, mobile device A 120 initiates the NAT traversal request with the CDX 110 service. In response, the CDX 110 service can read the public IP address and public port number used for the request and transmit this information from returns to the mobile device A 120. As described above, if a device is behind NAT, its public port and IP address will be different from its private port and IP address, respectively. That way, depending on the type of NAT that is used, the public IP address and port can be used to go through the "hole punch" through the NAT device to reach the mobile device.
[00078] In 222, the mobile device A 120 transmits a compatibility request 222 to the intermediation service 111. As described above, in one embodiment, the mobile device A communicates with the intermediation service 111 using sessions of the Transfer Protocol. Secure Hypertext ("HTTPS") (for example, using HTTPS request / response transactions). The compatibility request can include NAT type and the Hole Punch data (for example, the public IP address and port) previously determined for the mobile device A 120. In a modality that involves a multiplayer game, the compatibility request can identify the player on mobile device A (for example, using an individual player ID code), the game the user wants to play, the number of players to participate in the game, and / or other game configuration variables associated with the desired game ( as previously described with respect to figure 2a).
[00079] In 223-225, a group of transactions corresponding to transactions 220-222 is executed for the mobile device B 121 and in 226-228, a group of transactions corresponding to transactions 220222 is executed for the mobile device C 122. Thus, following transaction 228, the intermediation service 111 received compatibility requests on all three of the 120-122 mobile devices. In this specific example, compatibility requests result in 120-122 mobile devices matching a particular collaborative session, such as a multiplayer game (for example, users of these mobile devices may have selected the same game with the same, or similar, sets of variables, thereby resulting in a combination by the intermediation service 111).
[00080] The intermediation service 111 uses the data contained in each of the compatibility requests to generate Entry A, which it transmits to the mobile device A in 229; Input B, which it transmits to mobile device B at 230; and Entry C, which it transmits to mobile device C at 231. Although not shown in Figure 2b, the broker service 111 can use a push notification service to route Entries A, B and C to mobile devices A, B, and C, respectively (for example, such as the push notification service 1050 illustrated in Figures 11-12). An embodiment of the input data structure used for inputs A, B, and C is described above with respect to figure 3.
[00081] In 232, the mobile device A 120 communicates with NAT traversal service 290 to determine its own connection data. In one embodiment, this may include a standard ICE connection data transaction. As previously mentioned, connection data can include the public / private IP address, port and NAT type of the mobile device A 120.
[00082] The mobile device A 120 adds its connection data to Input A and, in 233, transmits Input A with the connection data to the CDX 110 service. In one mode, the CDX 110 service processes Input A as described above and, in 234, it transmits the connection data (which can be encrypted) to the mobile device B 121 and mobile device C 122. For these transactions, the CDX 110 service can use NAT traversal data from mobile devices B and C included with Entry A.
[00083] At 236-238, the transaction group corresponding to transactions 232-234 is executed using Entry B and at 238-240, the transaction group corresponding to transactions 232-234 is executed for Entry C. Thus, Following transaction 240, connection data was shared between each of the 120-122 mobile devices. Using connection data, P2P sessions are established between mobile devices A and B, mobile devices A and C, and mobile devices A and C.
[00084] As illustrated in figure 2c, an invitation service 112 can also be used with the CDX 110 service (instead of or in addition to the intermediation service 111). In one embodiment, the invitation service 112 processes invitation requests for P2P connections with mobile devices and / or specific users. The invitation service 112 can be implemented as a stateless service (i.e., a service that does not adhere to the current state of transactions between each of the wireless devices).
[00085] Back to this particular example, at 250, mobile device A 120 transmits a NAT-type request to NAT 291 traversal service. In response, NAT 291 traversal service can use several known techniques to determine the type of NAT used by mobile device A (some of which are described above). At 251, mobile device A 120 initiates the NAT traversal request with the CDX 110 service. In response, the CDX 110 service can read the public IP address and public port number used for the request and transmit this information back to the device mobile A 120. As described above, if a device is behind NAT, its public port and IP address will be different from its private port and IP address, respectively. Thus, depending on the type of NAT that is used, public IP address and port can be used to pass through the "hole punch" through the NAT device to reach the mobile device.
[00086] As with the brokerage service, in one mode, each of the mobile devices communicates with the invitation service 112 using Secure Hypertext Transfer Protocol ("HTTPS") sessions (for example, using order transactions / response from HTTPS).
[00087] In 252, mobile device A 120 transmits an invitation request to invitation service 112 that includes NAT traversal data from mobile device A (for example, NAT type, public IP address / port). In a modality that uses a push notification service (described in more detail below), the invitation request may also include the mobile device's push authenticator A. Invitation request 252 may also include an identification code that identifies one or more users / devices - in this case the users of the mobile devices B 121 and C 122. Several different types of identification code can be used. For example, in the case of a multiplayer game, the identification codes may comprise the specific player's game ID codes. In the case of an audio / video chat session, identification codes can comprise phone numbers or unique ID codes that identify one or more users of the user on the mobile device's "friends" list.
[00088] In one modality, the invitation service 112 reads the identification codes of the invitation request and performs a search in a registration database (not shown) to locate each of the mobile devices B and C. In one modality In particular, each of the mobile devices B and C has previously registered with a push service to receive push notifications from the invitation service 112. As such, in this mode, the invitation service 112 uses the push notification service to forward requests for invitation to the mobile device B 121 and mobile device C 122 in 253 and 254, respectively. Additional details related to a push notification service are described below (see, for example, figures 11-12 and associated text) and in the Push Notification Patent Application referred to above.
[00089] In one embodiment, invitation request 253 and 254 includes the input data structure illustrated in figure 3 and described above with respect to figures 2a-b. Specifically, the entry sent to mobile device B includes an encrypted list that identifies mobile devices A and B and the entry sent to mobile device C includes an encrypted list that identifies mobile devices A and C. In one embodiment, because the invitation service 112 may not yet have the NAT traversal data from mobile device B, the "entry" in 253 may include other information that identifies mobile device B. For example, as shown below with respect to modalities using the repeat service and service push notification (see, for example, figures 11-12), the "entry" in 253 can include NAT traversal data from mobile device A, the ID code of device A, the push authenticator of device A, ID code of device B, and the push authenticator of mobile device B. The same types of information can be provided in 254 for mobile devices A and C.
[00090] At 255, mobile device B can communicate with NAT 291 traversal service to determine its type of NAT, and in 256, mobile device B can communicate with CDX 110 service to determine its traversal data. NAT (for example, public IP address / port). At 257, mobile device B transmits an invitation response to invitation service 112 containing identification code from mobile device A and mobile device B, NAT traversal data and, if the push notification service is used, push authenticators from mobile devices A and B. In 258, mobile device B can retrieve its current connection data by communicating with NAT 290 traversal service. In 259, mobile device B transmits its input (Input B) with its current connection data to the CDX service 110. In response, the CDX 110 service processes the entry as described above and sends the connection data to the mobile device A 120.
[00091] Upon receiving the invitation response from the mobile device B, the invitation service 112 can generate an encrypted entry from the mobile device A and transmit the entry to the mobile device A in 260. In one embodiment, the entry includes crossing data from NAT, NAT type and push authenticator (if push notification service is used) for mobile devices A and B. The "entries" described with respect to figure 2c can be the same or different from the "entry" data structures described with respect to brokerage service 111. For example, instead of generating an encrypted "entry" as described above, invitation service 112 can simply generate a unique session ID to identify the invitation session with each of the mobile devices.
[00092] In 261, mobile device A retrieves its current connection data by communicating with NAT 290 traversal service. Mobile device A can then add its connection data to the input and, in 262, transmit the input with its connection data to the CDX 110 service. The CDX 110 service processes the entry as described above and sends the connection data from mobile device A to mobile device B. Finally, in 263, mobile devices A and B use the connection data exchanged to open a direct P2P connection. As described below, in cases where the NAT types of the mobile device A and B are incompatible, a retry service can be used to allow communication between mobile devices A and B.
[00093] At 264-272, the mobile device C 122 and the mobile device A can perform a series of transactions to establish a P2P connection as described in 255-263 for mobile devices B and A. Specifically, in 624, the mobile device C 122 communicates with NAT traversal service 291 to determine its NAT type and, in 265, communicates with the CDX 110 service to determine its NAT traversal data (for example, public IP address / port). At 266, mobile device C transmits an invitation response that contains the NAT type of mobile device A and mobile device C, NAT traversal data and push authenticator (if the push notification service is used). In 267, mobile device C retrieves its current connection data via NAT P2P crossing service 290, and in 268, mobile device C adds its connection data to Input C and transmits Input C to the CDX 110 service. The CDX 110 service processes the entry as described above and the connection data from the mobile device C refers to the mobile device A 120.
[00094] In 269, mobile device A 120 receives the invitation response from mobile device C of invitation service 112 which includes both the NAT type of mobile device A and C, NAT traversal data and push authenticators (if the push service is used). At 270, mobile device A retrieves its current connection data from the NAT 290 traversal service, adds its current connection data to Entry A, and at 271, transmits Entry A to the CDX 110 service. Alternatively, transaction 270 can not be necessary because the mobile device determined its connection data in transaction 261. The CDX 110 service processes Entry A as described above and sends the connection data from mobile device A to mobile device C. Finally, in 272, the mobile device A and C use the connection data exchanged to establish a direct P2P 272 connection.
[00095] In one embodiment, the invitation service 112 and the intermediation service 111 can depend on a push notification service (not shown) to forward data to mobile devices. For example, in figure 2c, invitation requests 253 and 254 can be forwarded to the mobile devices B 121 and C 122 via the push notification service. Similarly in figure 2a, entries A and B can be forwarded to mobile devices A 120 and B 121. In one mode, when a mobile device is activated on the network, it registers its push authenticator in a central registration directory accessible by the notification service push. In one embodiment, the registration directory is associated with a password-protected user ID or a phone number with a push authenticator. If the push authenticator can be identified in the directory, the push notification service can use the push authenticator to transmit push notifications to the mobile device. In one embodiment, the push notification service is the Apple Push Notification Service ("APNS") designed by the assignee of this patent application and described, for example, in the Push Notification Patent Application referred to above. It should be noted, however, that a personal notification service is not required by the modalities of the invention shown in figures 2a-c. For example, pushn notifications are not required for the CDX 110 service to perform its operations as described in this order.
[00096] Figure 4 illustrates a method that can be implemented by a CDX 110 service to exchange connection data and figure 5 illustrates a method that can be implemented by a mobile device to exchange connection data and establish a P2P connection. Certain aspects of these methods have already been described above with respect to figures 1-2c. In particular, these methods can be implemented within the context of the network architecture shown in figures 1-2c but are not limited to that architecture. In one embodiment, the methods are incorporated into the program code which, when executed by a processor, causes the operations of the methods to be performed. The program code can be stored in a machine-readable medium, such as a random access memory ("random access memory") while it is being executed by the processor. The processor can be a general-purpose processor (for example, an Intel® CoreTM processor) or a special-purpose processor. However, the methods can be implemented using any combination of machinery, software, and firmware. In addition, the program code can be stored on a non-volatile storage device, such as a hard disk drive, optical disc (for example, a Digital Video Disc or Compact Disc) or a non-volatile memory, such as a device flash memory.
[00097] Moving now to the method shown in figure 4, in 401, the NAT traversal request (also sometimes referred to as a "hole punch" request) is received by a particular mobile device - "mobile device A" in the example. At 402, the NAT traversal response is generated and transmitted to the mobile device A. In one embodiment, NAT traversal response generation may include determining the current public IP address / port and / or NAT type of the mobile device A .
[00098] An entry of the mobile device A can later be generated and encrypted by an entity that generates the entry, such as the intermediation service 111 or invitation service 112 described above. In 403, the input generated for mobile device A ("Input A") is received which includes NAT traversal data (for device A and one or more other devices) and connection data from device A. In 404, the entry is authenticated using the message authentication code and the Hole Punch data is decrypted using the same CDX entry key as that used by the entry generation entity to encrypt the entry. As mentioned above, in one embodiment, the correct CDX input key is identified using an expiration time / date associated with the CDX input key.
[00099] In 405, NAT traversal data from mobile devices is extracted. At 406, connection data from mobile device A is transmitted to each of the pairs using NAT traversal data. In 407, acknowledgments are received from each of the peers. If acknowledgments have not been received from all pairs, determined in 408, then the connection data from mobile device A is retransmitted to those pairs that did not respond in 409. When all connection data is recognized, determined in 408, the method ends.
[000100] In one embodiment, the method shown in figure 4 can be performed for each of the pairs involved in the P2P transaction to ensure that each pair receives the connection data necessary to establish a P2P connection.
[000101] Figure 5 illustrates a method that can be performed by a mobile device according to the modalities of the invention described in this application. At 501, the NAT traversal request is transmitted, and at 502, the NAT traversal response is received. As previously described, NAT traversal data contained in the response may include the requesting device's public port / IP address. At 503, a compatibility request is transmitted containing NAT traversal data. An entry from the mobile device can subsequently be generated and encrypted by an entity generating the entry, such as the intermediation service 111 or invitation service 112 described above. As an alternative to the input data structure described above, the broker service 111 and / or the invitation service 112 can simply identify each of the participants using a unique session ID.
[000102] In 504, the entry can be received; in 505, the mobile device's connection data is added to the entry; and in 506, the entry with the connection data is transmitted. At 507, the connection data needed to establish P2P connections with one or more other pairs is received. In 508, acknowledgments that indicate that one or more other wireless devices received the connection data transmitted in 506 are received. If all acknowledgments are not received then, at 510, the connection data is relayed to those mobile devices from which acknowledgments have not been received. If all acknowledgments are received, determined at 509, then the connection data received at 507 is used to establish P2P sessions with other mobile devices. Apparatus and Method for Establishing and Using Backup Communication Channels
[000103] Today's mobile devices are capable of communicating on a variety of different communication channels. For example, the Apple iPhone ™ is capable of communicating over Wi-Fi networks (for example, 802.11b, g, n networks); 3G networks (for example, Universal Mobile Telecommunications System ("UMTS") networks, High Speed Data Packet Access networks ("HSUPA"), etc.); and Bluetooth networks (known as personal area networks ("PAN’s")). Future mobile devices will be able to communicate on additional communication channels, such as WiMAX, Advanced International Mobile Telecommunication ("IMT"), and Advanced Long Term Evolution ("LTE"), to name a few.
[000104] In operation, the current mobile devices select a primary communication channel among the group of available channels. For example, mobile devices are often configured to choose a Wi-Fi connection if one is available and to choose a cellular data connection (for example, a UTMS connection) if Wi-Fi is not available.
[000105] In an embodiment of the invention, a group of mobile devices initially establishes primary point-to-point communication channels ("P2P") using standard ICE connection data exchanges and / or using connection data exchange techniques described above . Mobile devices can then exchange connection data on the primary channels to establish one or more secondary communication channels that are used as backup channels if any of the primary channels fail. In one embodiment, the secondary communication channels are kept open by NAT firewalls, periodically transmitting "heartbeat" packets on these channels.
[000106] As used in this application, a communication "channel" refers to the complete network path between two mobile devices and a communication "connection" refers to a particular connection used in the communication route. For example, if device A is connected to the Internet using a Wi-Fi connection and device B is connected to the Internet using a 3G connection, then the "channel" between device A and device B is defined by both the Wi- Fi and 3G connection; device A has a Wi-Fi communication "connection"; and device B has a 3G communication "connection". As such, if device A switches from a Wi-Fi connection to a 3G connection, then the "channel" between device A and device B is modified despite the fact that device B's 3G connection remains the same.
[000107] Specific examples in which mobile devices establish primary and secondary communication channels will now be described with reference to figure 6. It should be noted, however, that the underlying principles of the invention are not limited to the particular set of communication connections and channels of communication shown in figure 6.
[000108] In figure 6, the mobile device A 601 is able to connect to a 610 network (for example, the Internet) on the communication connection 605 with the NAT device 611 and on the communication connection 606 with the NAT device 612. Similarly, device C 603 is able to connect to network 610 on communication connection 609 with NAT device 613 and on communication connection 610 with NAT device 613. By way of example, and not limitation, communication connections 605 and 609 can be 3G communication connections and communication connections 606 and 610 can be Wi-Fi communication connections.
[000109] Consequently, in this example, there are four different communication channels that can be established between mobile device A and mobile device B: a first channel that uses connections 605 and 609; a second channel using connections 605 and 610; a third channel using connections 606 and 609; and a third channel using connections 606 and 610. In one embodiment, mobile devices A and B will select one of these channels as the primary communication channel based on a prioritization scheme and select three remaining channels as backup communication channels. For example, a prioritization scheme might be to select the channel with the highest bandwidth as the primary channel and use the remaining channels as the secondary channels. If two or more channels have comparable bandwidth, the prioritization scheme may include selecting the least expensive channel (assuming the user pays a fee to use one or more of the channels). Alternatively, the prioritization scheme may be to select the least expensive channel as the primary channel and, if the price of each channel is the same, to select the highest bandwidth channel. Several different prioritization schemes can be implemented while still complying with the underlying principles of the invention.
[000110] The mobile devices A 601 and C 603 can use the techniques described above to establish the primary communication channel (for example, exchanging connection data through the CDX 110 service). Alternatively, mobile devices 601, 603 can implement standard Internet Connectivity Establishment ("ICE") transactions to exchange connection data. Despite how the primary channel is established, as it is, the mobile devices A 601 and C 603 can exchange connection data for the secondary communication channels on the primary communication channel. For example, if the primary communication channel in figure 6 includes communication connection 606 and communication connection 609, then this connection, once established, can be used to exchange connection data for secondary communication channels that include connections 605 and 609 communication. In this example, the connection data exchanged on the primary communication channel can include NAT traversal data and NAT type data for NAT 611 and NAT 613, including public and private IP addresses / ports for each of the mobile devices.
[000111] Once the secondary communication channels have been established, they are kept open using heartbeat packets. For example, device A may periodically transmit a small "heartbeat" packet to device C and / or device A may periodically transmit a small "heartbeat" packet to device C to ensure that the NAT ports used for the secondary channels remain open. (NATs will often close doors due to inactivity). Heartbeat packets can be UDP packets with no payload, although the underlying principles of the invention are not limited to any particular packet format. Heartbeat packets can be UDP packets with a self-identifying type field in their payload header, and can contain additionally formatted optional information including but not limited to a channel lifetime value.
[000112] As illustrated in figure 7, each mobile device 601 stores and maintains a data structure 710 (for example, a table, text file, database, etc.) containing a list of primary and secondary communication channels. A separate entry is provided for each communication channel and includes the connection data needed to use that channel (for example, private / public IP address, NAT type, etc.), and the current status of that channel (for example, primary , secondary 1, secondary 2, etc.).
[000113] In one embodiment, communication interfaces 701 and 702 are used to communicate on communication connection 605 and communication connection 606, respectively. The fault detection module 705 can be run on the mobile device 601 to detect when a particular communication interface / connection has failed or degraded below a specified threshold. In response, connection management module 706 can read primary / secondary connection data 710 to promote a secondary channel having the next highest priority over the primary channel. The prioritization of the secondary channels can be carried out using the same principles as those discussed above for the primary channels (for example, based on bandwidth, costs, reliability, etc.). Once a secondary channel has been selected, the connection management module 706 can transmit a connection failure indication to connect the management modules to other mobile devices, instructing those devices to promote the secondary communication channel to a communication channel. primary. Those devices will then start using the connection data associated with the selected primary channel.
[000114] In one embodiment, a complete "failure" of the primary communication channel is not required to force an exchange for one of the secondary communication channels. For example, in one embodiment, if the primary communication channel is sufficiently degraded (for example, below a particular bandwidth, bit rate, or confidence threshold), then a modification to a secondary channel can be implemented as described in this order. In one embodiment, switching to the secondary channel is only performed if the secondary channel is capable of supporting better performance (for example, bandwidth, bit rate or confidence) than the current primary channel.
[000115] Figure 8a illustrates the same network configuration as shown in figure 6 with the addition of the mobile device B 602 connected directly to the network 610 and connected to the device C 603 by a private network connection 620. The private network 620 can be , for example, a Bluetooth PAN connection between device B 602 and device C 603. It can be seen from this example that switching from a primary channel to a secondary channel can dramatically change the network topology. For example, as shown in figure 8b, if primary channels 801 for mobile devices include communication connection 609 (resulting in direct connections between device devices A, B and C) and secondary channels include private network 620, then the network topology can be modified as illustrated in figure 8c because the only path from device A and device C to communicate using the private network is through device B. Although this is a simplified example with only three devices, a significantly larger number of devices can be used, resulting in a variety of different network topology configurations when switching between primary and secondary communication channels.
[000116] A modality of a method for establishing and maintaining secondary channels is illustrated in figure 8. In one embodiment, the method can be performed by the connection management module 706 on each mobile device. However, the method is not limited to any particular device configuration.
[000117] In 901, a primary P2P communication channel is selected. As mentioned above, the primary channel can be selected based on a predefined prioritization scheme. For example, certain types of communication channels can be prioritized over other types of communication channels. Channels can also be prioritized based on variables, such as bandwidth, cost to use and / or reliability.
[000118] In 902, the backup P2P communication channels are established. In one embodiment, this is accomplished by sharing connection data between all of the mobile devices on the primary communication channel. In 903, the backup channels are maintained. In one embodiment, this involves transmission data periodically on the secondary communication channels (for example, in the form of periodic heartbeat packets).
[000119] In 904, if the primary P2P channel fails (for example, because the communication connection of a particular mobile device has decreased or the mobile device has been moved outside the communication connection range), then in 905, mobile devices promote higher priority support channel to the primary channel. In one embodiment, this involves the mobile device with the failed connection that transmits a notification of its connection failure to other devices on the secondary channel. Finally, in 906, the backup channel is made the primary channel and the process reverts to 902 (in which any additional backup channel is discovered and added to the prioritization scheme). Apparatus and Method of an Invitation Service to Establish Point-to-Point Communication Channels (P2P)
[000120] As illustrated in figure 10, in addition to the CDX 110 service, intermediation service 111 and invitation service 112 (some modalities of which are described above), an embodiment of the invention can include a registry / directory service 1052, a service push notification 1050, and a repeat service 1051. As mentioned above, in one embodiment, the invitation service 112 and / or the broker service 111 can use the registration service / directory 1052 to identify registered mobile devices and the service push notification 1050 to forward data to mobile devices. In one embodiment, when a mobile device is activated on the network, a "push authenticator" (sometimes referred to as "a notification service account identifier" is registered in the Push Notification Patent Application) with a maintained database through the 1052 registry / directory service by associating the push authenticator with a password-protected user ID or a phone number. If the push authenticator is identified in the registration directory (for example, by performing a query with a user ID), the push notification service 1050 can use the push authenticator to transmit push notifications to a mobile device. In one embodiment, the push notification service is Apple's Push Notification Service ("APNS") designed by the assignee of this patent application and described, for example, in the Push Notification Patent Application referred to above.
[000121] Figure 11 illustrates a modality of the invention in which the push notification service 1051 is used to establish a direct P2P connection between two mobile devices and figure 12 illustrates a modality that is used to establish a P2P connection by the replay service. 1051. As described below, the decision as to whether to use the 1051 retry service to establish a P2P connection can be based on the practicality of establishing a direct P2P connection between mobile devices (for example, based on NAT compatibility issues) ).
[000122] Moving now to figure 11, in 1101, the mobile device A 120 transmits an invitation to invite the mobile device B 121 to invite the mobile device B to a P2P communication session (for example, a collaborative video game , a P2P video chat, etc.). In one embodiment, the invitation includes a User ID code that identifies mobile device B 121 (and / or the user of mobile device B) within the context of a particular online application. For example, the user ID code can be the player ID for a particular multiplayer game, P2P and can take the form, for example, of a Universally Unique Identifier (UUID). Alternatively, in some embodiments, the ID code can be a phone number for the mobile device B 121. A game ID code can be used to identify the multiplayer game that mobile device A is inviting mobile device B to join . A bucket ID can be used to identify a configuration for that game (as described in this order with respect to the brokerage service).
[000123] Invitation 1101 may also include an ID code identifying mobile device A 120 and NAT traversal / connection data associated with mobile device A (for example, IP addresses and public / private ports of mobile device A and type from NAT to device A's NAT device). NAT traversal / connection data or NAT type data may have been previously determined by mobile device A prior to invitation request 1101 (for example, via NAT traversal, NAT type and connection data transactions, such as those discussed above with respect to figures 2a-c). As previously mentioned, invitation request 1101 can take the form of an HTTPS request. In addition, for additional security, invitation order 1101 may include a client certificate signed by a pre-specified certificate authority.
[000124] Despite the type of private ID code used to identify mobile device B, the ID code is received by invitation service 112 and, in 1102, invitation service 112 can perform a search on directive service 1052 (no shown in figure 11) to identify a notification service account identifier, such as a push authenticator used to forward notifications to mobile device B ("push-authenticator-B"). In one embodiment, search operations can perform multiple checks to determine whether the invitation should be allowed. First, you can confirm that the mobile device identification code ("ID-A") and device A push authenticator ("push-A-authenticator") is a registered association within the directive service database. Search operation 1102 can also confirm that the user of the mobile device A allows inviting the user of the mobile device B (for example, the user of the mobile device B can specify that only those other users who have registered as B's friends can invite user B; or can specify that no invitations are allowed). In one mode, if any of these checks fail, the invitation is canceled, and invitation service 112 returns an error to mobile device A.
[000125] While a "push authenticator" is described in this embodiment, it should be noted that the underlying principles of the invention are not limited to the use of a "push authenticator" or any other particular data structure to authenticate and forward notifications to mobile devices.
[000126] In one embodiment, after the push authenticator is identified, the invitation service 112 can generate a secure, single-use "session authenticator" intended for the invitation session and used to identify the session in all additional transactions. A copy of the session authenticator is then transmitted back to mobile device A 120 and sent to mobile device B with the invitation request. In one embodiment, the session authenticator is used in conjunction with the input data structure described above, and in another embodiment, only the session authenticator is used.
[000127] In 1103, invitation service 112 transmits a push request to push notification service 1050. In one embodiment, the push request can include NAT traversal data from mobile device A, device ID code A, "push -token-A ", device ID code B, and push-token-B. In one embodiment, this information can be packaged within an "input" data structure and encrypted as described above. In another embodiment, the data is simply transmitted with an invitation session ID.
[000128] As the mobile device B 121 in this example registers with the push notification service 1050, the push notification service 1050 is capable of locating and forwarding the invitation request to the mobile device B 121 in 1104. The forwarded invitation 1104 can include the session authenticator, mobile device A data / connection NAT traversal data, and mobile device ID code B. In response to the invitation request, mobile device B can determine its network information (for example , NAT traversal / connection data, NAT type, etc.) by making a call to the NAT traversal service or the CDX 110 service as described above.
[000129] In 1105, mobile device B accepts the invitation. The acceptor 1105 can take the form of an HTTPS call to invitation service 112 and can include a client certificate signed by the pre-specified certificate authority (mentioned above with respect to the invitation request). In one embodiment, the acceptor 1105 can include mobile device ID code A and B and NAT traversal / connection data and / or NAT type of mobile devices A and B. The acceptor 1105 can also include device push authenticators. A and B mobile phones and / or session authenticator. In one embodiment, the acceptor 1105 may also contain an indication as to whether it is a retry of a previous failed direct connection attempt. However, in another modality, the acceptor 1105 does not contain the indication of a new attempt. Instead, to detect a failed P2P connection attempt, one of two mobile devices can transmit a "special retry invitation" to invitation service 112. In response, the service can directly initiate the series of retry transactions described below with respect to figure 12 (starting in 1201).
[000130] In 1106, invitation service 112 can perform a compatibility check to determine whether a direct P2P connection between mobile devices A and B is feasible. For example, in one embodiment, if the acceptor 1105 received from mobile device B indicates that it is a retry of a previous failed direct connection attempt (or a specified number of previous failed direct connection attempts), then the invitation may conclude that a direct P2P connection is unenforceable. Invitation service 112 can compare NAT type data from mobile devices A and B to determine whether NAT devices from mobile devices A and B will support a direct P2P connection. It is known that certain compatibility of NAT types are incompatible to establish P2P connections. For example, a full cone NAT can be used with any other type of NAT except NAT closed / with firewall to establish a direct P2P connection. On the other hand, symmetric NAT can only be used with a full cone NAT to establish a direct P2P connection. The feasibility of combining several types of NAT in one embodiment of the invention is shown in table 1400 of NAT compatibility shown in figure 14, in which the columns represent types of NAT from a mobile device (for example, mobile device A) and the lines represent NAT types from another mobile device (for example, mobile device B). A "1.0" in a cell indicates which types of NAT in the associated row and column are compatible, and a "0.0" indicates which types of NAT are incompatible.
[000131] In one embodiment, if compatibility check 1106 determines that a direct P2P connection is unenforceable, then invitation service 112 can transmit a repeat search request 1201 as described below with respect to figure 12. If, however, compatibility check 1106 determines that a direct P2P connection is feasible, so invitation service 112 can transmit a push request 1107 to push notification service 1050 containing mobile device acceptance B of the mobile device invitation A. Push request 1107 and subsequent push communication 1108 to mobile device A of push notification service 1050 can include both the session authenticator and both the mobile device A and B push authenticator, ID code, and / or traversal / connection data. NAT. In one embodiment, this information can be packaged within the "entry" data structure described above (see, for example, figures 2a-c and associated text) and can be encrypted using a unique key. Alternatively, this information can simply be transmitted with a unique invitation session ID. The 1050 invitation service can also notify mobile device B that a direct connection will be attempted.
[000132] At this stage, mobile devices A and B have enough information to establish a direct P2P connection. In one embodiment, this is accomplished using the CDX 110 service as described above. For example, mobile device B adds its connection data to Input B and, in 1109, transmits Input B (with connection data) to the CDX service. Only before this transaction, mobile device B can implement a transaction, such as transaction 235 shown in figure 2b in order to ensure that its connection data is current. The CDX 110 service then authenticates the entry (for example, using the unique session key as described above), extracts the connection data from mobile device B, and sends the connection data to mobile device A in 1110. Similarly, the device mobile A adds its connection data to Entry A and, in 1111, transmits Entry A (with connection data) to the CDX 110 service. Only before this transaction, mobile device A can implement a transaction, such as transaction 232 shown in figure 2b to ensure that your connection data is current. The CDX 110 service then authenticates the entry (for example, using the unique session key as described above), extracts the connection data from mobile device A and sends the connection data to mobile device B in 1112. Finally, in 1113, mobile devices A and B establish a direct P2P connection using the connection data exchanged.
[000133] Moving now to figure 12, if the compatibility check 1106 determines that a direct P2P connection is unenforceable, then the invitation service 112 can transmit a repetition search request 1201 to the repetition service 1051 to determine a host repetition to be used by each mobile device. Order 1201 may contain the networking information of mobile devices A and B (for example, NAT traversal / connection data and / or NAT type data) that is used by the 1051 replay service to select replay hosts appropriate from both mobile devices. As illustrated in figure 13, a repeat service modality 1051 includes a plurality of repeat hosts 1302-1303 and a repeat host database 1301 that contains network information related to each of the repeat hosts. The invitation service 112 transmits a repeat search request 1201 to a repeat search service 1300, which queries the repetition host database 1301 using the network information for mobile devices A and B. To receive the results of database, the 1300 repeat search service provides a 1202 response identifying the selected repeat hosts 1302-1303.
[000134] In one embodiment, the repetition search response 1202 contains a repetition authenticator generated by the repetition service and the network addresses (IP addresses / ports) of the repetition hosts 1302-1303 to be used by mobile devices A and B for the repeat connection. In one embodiment, the replay authenticator associates with the replay session and is used by replay hosts 1302-1303 to authenticate mobile devices A and B to connect to the 1051 replay service. The authenticator can take several forms including, for example, example, unique ID replay session ID code, a digital certificate and / or a unique encryption key associated with the replay session.
[000135] In 1203, the invitation service transmits a retry response 1203 to the mobile device B 121 containing an indication that a retry connection will be made. In one embodiment, the retry response 1203 may include the retry authenticator and information about the network of the repeat host B 1303. In one embodiment, the response 1203 may be sent directly to the mobile device B (bypassing the notification service push 1050) because it is being sent in response to the acceptor of the mobile device B 1105.
[000136] Invitation service 112 transmits repetition response 1204 to mobile device A which may include the repetition authenticator and information about the network of repetition host B 1303. In this example, response 1204 is forwarded to mobile device A through the push notification service 1050 in transaction 1205.
[000137] In 1206, the mobile device A 120 uses network information for the repeating host A 1302 to establish a connection with the repetition service 1051. Similarly in 1207, mobile device B 121 uses network information from the repeating host B 1303 to establish a connection to the 1051 retry service. In each of these transactions, new passages are opened at any NAT firewall from mobile devices A and B and NAT traversal / connection data from mobile devices A and B can be determined by repetition service 1051 and returned to mobile devices A and B, respectively (for example, determining the devices' IP / public port). In one embodiment, the 1051 replay service and mobile devices A and B implement the Crossover Protocol Using Repeating NAT ("TURN") which, as understood by those skilled in the art, allows an element behind NAT or firewall to receive data input over TCP or UDP connections.
[000138] In 1208, mobile device A transmits a repeat update of invitation service 112 which is sent to the push notification service in 1209 and forwarded to mobile device B in 1210. Similarly, on mobile device B 1211 transmits an update of repetition of invitation service 112 which is dispatched to the push notification service in 1212 and forwarded to mobile device A in 1213. The repetition update transmitted by mobile device A may include the session authenticator, the ID code of each device, and NAT traversal / connection data determined by repetition in 1206 and 1207 (ie, with mobile device A sending its NAT traversal / connection data to mobile device B and vice versa). In one mode, the update update operations are performed because the NAT information for each mobile device can be modified.
[000139] Finally, on mobile devices A and B 1214 and 1215, respectively, they establish a P2P connection through the 1051 repetition service. In one mode, the repetition connections can be established when the mobile device A sends data of crossing / connection of NAT from mobile device B to repetition service 1051, and vice versa, thereby allowing the repetition service to determine the correct path for the repetition of each repetition host from point 1302-1303.
[000140] Using the techniques described above, invitation service 112 can be implemented as a stateless service that is inherently scalable and resilient, even in a large-scale system with a vast number of mobile devices. For example, because the push notification service 1050 is inherently capable of finding and forwarding content to registered mobile devices, the invitation service should not track each device's current position. Additionally, because devices can transmit entire session state data with each request and response, the invitation service must never maintain any status information per connection, thereby reducing storage and processing of invitation service requirements. Such an implementation is particularly useful in a large-scale system. System and Method for Compatible Users for Online Sessions
[000141] As illustrated in figure 15, an intermediary service 111 modality may include an intermediary scheduler 1501 to receive compatibility requests and forward combination responses to mobile devices 120122; a database 1512 for storing compatibility orders in order table 1502 and for storing compatible data in a compatible set identifier table ("MSI") 1503; and one or more intermediaries 1510 to bring compatibility requests from database 1512, performing matching operations, and storing compatibility results back to database 1512. It should be noted, however, that the underlying principles of the invention are not limited to the specific architecture shown in figure 15.
[000142] In one embodiment, the intermediation scheduler 1501 acts as an interface for the intermediation service 111, receiving requests from mobile devices 120-122, translating those requests into order storage orders in the database 1512, reading results from compatibility of database 1512, and translating and communicating those results to mobile devices 120-122.
[000143] In the operation, when a new compatibility order arrives, the intermediation scheduler 1501 can store the order within a row of the order table 1502. In one embodiment, the scheduler 1501 assigns to each compatibility request an ID code of order ("RID"), illustrated simply as "A", "B" and "C" in figure 15 (corresponding to mobile devices A, B and C, respectively). While shown using a letter designation in figure 15 for simplicity, the RID code can be a string, integer, or any other variable type suitable for tracking compatibility requests within the database.
[000144] Each compatibility order can be assigned a compatible set identifier value ("MSI") which is stored in order table 1502. In one embodiment, the MSI can identify the specific application for which a compatibility is being requested and / or the configuration parameters to be used for that application. For example, an MSI value of 12: 4 can identify a particular multiplayer game with the identifier "12" and can identify a particular game configuration with the identifier "4". More specifically, the ID code of 12 can identify a particular multiplayer racing game and the ID code of 4 can specify a particular race track, speed, or player experience level of the racing game. In one embodiment, they provide application developers with the option of specifying any configuration parameter applied using MSI values in this way. In one embodiment, instead of specifying an MSI directly, application developers specify a game ID (to identify a particular game) and a bucket ID (to identify a particular game configuration) and these values are mapped to a value of MSI by the 1501 intermediation scheduler.
[000145] Additionally, several different MSI values can be used within a single MSI to specify multiple different configuration parameters (for example, 12: 4: 1 could represent: 12 = racing game; 4 = track; and 1 = level of experience). As described in detail below, in one embodiment, each MSI is used by an intermediary 1510 to identify the group of compatibility requests in which intermediation operations can be performed (for example, requests are grouped based on MSI and compatibilities are performed within each MSI group). In one embodiment, each MSI can be dynamically modified / selected by the scheduler to include a partition ID identifying different machine partitions. For example, if a particular MSI becomes overloaded, the scheduler can divide the MSI between two or more different servers and / or storage partitions (for example, using designations such as 4: 3: 1 and 4: 3: 2 where the latter digits identify partitions 1 and 2, respectively). A different intermediary can then independently recover and process requests from each of the different MSIs from each of the different servers.
[000146] As illustrated in figure 15, the compatibility order data can also be stored within the order table 1502 of each order. The order data can include any data that can be used to make an intermediary decision and / or any data needed to access the mobile device that initiates the order on the network. For example, in one embodiment, the compatibility order data for each order includes NAT type data and / or NAT traversal / connection data for the mobile device initiating the order. Other types of order data can also be stored within order table 1502, such as device connection speed (100kbps, 1Mbps, etc.), connection type (for example, 3G, EDGE, WiFi, etc.), device position (for example, determined by geolocation techniques), language (English, Spanish, etc.), and / or user preferences. The order data can be determined by each 120-122 mobile device and transmitted to the intermediary scheduler 1501 with each compatibility order. For example, each mobile device can determine its connection data, connection type, device position, etc., using various techniques, some of which are described in this application (for example, communicating with NAT traversal server to determine traversing NAT / connection data, using GPS to determine the position of the device, reading information over HTTP to determine the language, etc.).
[000147] As illustrated in figure 15, in one embodiment, each active MSI can be designated by a line in the MSI table 1503. In one embodiment, when a new order arrives, in addition to adding the order to the order table 1502, the scheduler 1501 also checks the MSI table 1503 to determine if an MSI already exists for that order (that is, if other orders having the same MSI have already been received). If no MSI compatibility is found, then scheduler 1501 can create a new entry in the MSI table 1503 of the new order. If an MSI compatibility is found, then the scheduler can simply add the new order to order table 1502 as described above.
[000148] Since order table 1502 and table MSI 1503 are updated by broker scheduler 1501, an example of broker module 1510 (hereinafter simply referred to as "broker 1510") brings the data to perform broker operations . Multiple broker examples can be concurrently executed to place broker requests and a single broker 1510 can concurrently process multiple broker operations on multiple different MSI groups.
[000149] In one embodiment, when an intermediary 1510 becomes available (for example, after completing matching operations for an MSI group or after being initialized), it consults the MSI table 1503 to identify a new MSI to process. In figure 15, the value "N / A" in the brokerage ID fields of MSI 3: 1 indicates that the responsibility for processing this MSI has not yet been assigned to an intermediary. In one embodiment, each MSI entry has a time stamp and intermediary 1510 selects an MSI with the oldest time stamp.
[000150] In one embodiment, when an intermediary 1510 assumes responsibility for a particular MSI, it updates its intermediation ID code in the MSI table 1503 and specifies a lease duration for that MSI (for example, 5 seconds). In one mode, intermediary 1510 constantly updates the lease amount as it processes compatibility for that MSI. The grant values can be used to identify MSIs that have been assigned to failed 1510 intermediaries. For example, if the lease amount has expired, that MSI can be claimed by a new intermediary despite the fact that the MSI table 1503 indicates that the MSI is already assigned to an intermediary.
[000151] Once broker 1510 has assumed responsibility for an MSI, it can refer to order table 1502 to read orders associated with that MSI in memory. Intermediary 1510 can then perform compatibility operations to match users and mobile devices according to the group with compatibility criteria (for example, as described below). Broker 1510 can update order table 1512 to indicate when mobile device compatibility has been made. For example, the intermediary can remove the MSI values from the MSI column in order table 1512 and enter a predetermined value to indicate that the combination has been completed. In addition, intermediary 1510 can update each participant's "order data" field to identify other participants with which that participant has been matched (for example, by writing the NAT traversal / connection data needed to communicate with other participants).
[000152] Scheduler 1501 can periodically refer to order table 1502 to identify complete compatibilities. In response to the detection of a complete compatibility, the scheduler 1501 can transmit a push notification to the mobile devices involved in the compatibility (for example, using the push notification techniques described in this application and in the copending patent applications). In one embodiment, the push notification includes the "input" data structure described above. Mobile devices can then use each of their inputs to exchange connection data via the CDX 110 service as described above.
[000153] In addition to the use of push notifications, in a modality, mobile devices 120-122 can periodically consult scheduler 1501 to determine whether a match has been made. Periodic consultations are useful in the event that the notification did not make it to the mobile device. However, because a push architecture is used, periodic consultations can be established at a relatively low rate, thereby reducing the burden on the intermediation service 111.
[000154] Figure 16 illustrates an exemplary modality of a method in which two mobile devices, A and B, are combined by the intermediation service 111. Figures 17a-d illustrate exemplary updates to the order table 1502 and the MSI table 1503 that can occur as the method progresses.
[000155] In 1601, a compatibility request is received from mobile device A. In 1602, the mobile device request A is entered in the order table and a new MSI entry (MSI 1: 1) is introduced in the MSI table (if one no longer exists), as illustrated in figure 17a. In 1603, a compatibility request is received from the mobile device B, and in 1604, the compatibility request from the mobile device B is also entered in the order table as illustrated in figure 17b.
[000156] In 1605, a particular example of an intermediary (intermediary # N) checks the MSI table and detects that MSI 1: 1 was not claimed by another intermediary example. Alternatively, the intermediary can detect an entry in the MSI table with an expired lease, indicating that the intermediary who previously influenced the MSI has failed. In one embodiment, MSI entries with overdue concessions are given higher priority than new MSI entries (which have not yet been designated as an intermediary). In addition, in one embodiment, relatively older MSI inputs may be given higher priority than relatively newer MSI inputs. Despite how the intermediary selects the MSI, when it does, it adds its identifier and establishes a new grant value for the MSI entry, as illustrated in figure 17c (for example, using a 5-second grant value in the illustrated example). The intermediary can then consult the order table and read the order table entries with that MSI in memory so that they can be processed.
[000157] In 1606, the intermediary performs a series of matching operations to select an appropriate compatibility for each of the orders. Certain modalities of compatibilization operations are described below with respect to figure 18. Briefly, in one modality, the variables that are evaluated to determine "appropriate" compatibilities include NAT type (for example, complete cone, port constrained, symmetrical, etc. .), type of connection (for example, WiFi, 3G, Edge, etc.), language associated with the user (derived from the accepted language header for HTTP request), and the age of each of the compatibility requests. In general, intermediary 1510 can try to make it compatible with mobile devices that have compatible NAT types (although the replay service can sometimes be used as described below), the same connection types, and the same language. In one embodiment, intermediary 1510 can be more liberal with compatibility requirements based on the age of compatibility requests (that is, the older the request, the more liberally the compatibility restrictions will apply).
[000158] Returning to figure 16, in 1607, following the compatibility decision, intermediary 1510 can update the order table to indicate that the compatibility is complete, as indicated in figure 17a. As part of the update, the intermediary can also update the order data for mobile devices A and B. For example, in an embodiment, the intermediary 1510 writes NAT traversal / connection data for the mobile device B in the order data column of the mobile device A and writes the NAT traversal / connection data of mobile device A to the order column of mobile device B.
[000159] In 1608, scheduler 1501 can read the order table from beginning to end to identify order entries that have been matched. In one mode, when it detects that mobile devices A and B have been made compatible, it reads the order data (updated by the intermediary as described above), and generates a notification from mobile devices A and B. In one mode, the notification is the structure "input" data described above that is encrypted and includes NAT traversal / connection data for each mobile device. As previously described, in one embodiment, the push notification service 1050 is used to forward notifications to mobile devices A and B. In addition, mobile devices A and B can periodically poll scheduler 1501 to determine whether a match has been made. In this modality, the counting technique can be performed at a relatively slow rate to identify compatibilities that, for some reason, have not been successfully sent to one of the mobile devices. Using push notifications to manage the clearance order load significantly reduces the burden on the 111 brokerage service, which would otherwise be charged with the clearance of mobile device orders.
[000160] If additional compatibility requests are pending for the same MSI, determined in 1608, the intermediary can continue to match mobile devices / users within the MSI. In 1610, the matchmaker can reset the concession amount within the MSI 1503 table. In 1611, additional compatibilities are performed and the order table is updated (as described above). In 1612, additional compatibilities are read in the order table and the additional mobile devices are updated (as described above). If no further compatibility requests are pending for the MSI then, in 1609, the MSI entry is removed from the MSI table (for example, via a scheduler and / or intermediary delete command).
[000161] Figure 18 illustrates a modality of a method to perform compatibility between mobile devices / users (operation 1606 in figure 16). In 1801, all current MSI orders (for example, for a particular application / bucket combination) are arranged in pairs. In 1802, a "fit" of compatibility between each pair is assessed and, in 1803, the pairs are classified by descending adjustment. The "fit" is evaluated based on a plurality of different variables including, but not limited to, the type of NAT (eg, full cone, port restricted, symmetrical, etc.), type of connection (eg, WiFi, 3G, Edge, etc.), language associated with the user (derived from the language acceptance header for HTTP request), and the age of each of the compatibility requests. Other variables that can be assigned in the intermediation decision include the position of each of the mobile devices (for example, with an attempt to match users in a particular position); minimum and / or maximum requirements of the player (for example, specified by the user and / or application); whether one or more of the users included in the MSI are "friends" or have established a P2P connection previously (for example, with a preference to match "friends" or previous knowledge); and user experience with the application (for example, for a multiplayer game, the leader ratings of each user can be assigned, with a preference to match similarly experienced users).
[000162] As indicated in Table A below, in one modality, the assessment of "aptitude" is a numerical value between 0.0 and 1.0. Using a fluctuating value allows normalization of suitability for each criterion. To avoid doing fluctuation arithmetic, non-normalized integer values can be used with the proper assessment so suitability values can be compared.
[000163] In one modality, all criteria have their own binary where they are compatible (having a normalized value of 1.0) or not compatible (having a normalized value of less than 1.0). You can think of these as required criteria where the adjustment can change with age (as described below). If the position is added as a variable, then the best fit may be one with the player very close that matches the necessary criteria. Compatibility Capability - Table A

[000164] In one modality, the Adjustment is equal to the Sum of (Normalized Weight * Age Factor Value) for each of the aforementioned criteria. The Age Factor Value can start with a value of 1 and increase after a predetermined period of time has passed. Then it can continue to increase the more time it passes (for example, periodically increasing by a specified amount). In one embodiment, instead of using the Age Factor Value described above, age thresholds can be set as described below. The normalized / weighted values of certain variables, such as Type of Connection and Language can be applied above certain age thresholds (even if they do not match).
[000165] In one modality, the "adjustment" between a pair of orders, A and B, is the average of A's own with B and B with A. In addition, the adjustment of A with B of each factor can be adjusted based on the age of A (and vice versa). In one embodiment, a setting of 1.0 may be required for a compatible combination. This means that A and B will only match if the compatibility of NAT, Connection Type and Language combination (resulting in a normalized value of 1.0) or if A and / or B are old enough for some of the above variables (for example , Connection Type and Language) are not effectively ignored (using the age factor value above or the thresholds below). Ages - Table B

[000166] Age thresholds can be established as shown in Table B above. As each age threshold is passed (that is, as the order gets older than the specified threshold), the age factor value can be increased to successively higher values (for example, 1.5, 2.0, etc. .). Alternatively, or in addition, as different age thresholds are passed, the weighted values of certain variables can be added to the match decision (for example, such as connection type and language as described below).
[000167] In one embodiment, the order age limits specified in Table B are adjusted according to the combination flow rate of a given MSI. In one embodiment, the flow rate is specified as several compatibilities that are performed for a specified unit of time (for example, every 10 seconds, every minute, etc.). In this way, the flow rate provides an indication as to how busy a particular set of MSI is. In one embodiment, the busier the set, the lower each of the above thresholds can be defined in Table B above to increase the likelihood of a successful first match and to reduce the intermediary load. In addition, the load for a given MSI set can be provided to the end user (for example, in the form of an estimated time to match the value), so that the end user can select whether to attempt to introduce a multiplayer game that it is particularly busy. The charge amount can be provided to the user in the form of a push notification.
[000168] Now moving to each of the variables in Table A, in one mode, NAT compatibility is determined from the NAT 1400 compatibility diagram shown in figure 14. If two NATs are determined to be compatible based on this diagram, then the NAT compatibility weight can be applied. Connection Type - Table C

[000169] The connection type can be evaluated using a diagram such as the one shown above as Table C. In this example, if the connection type of devices A and B is the same (as indicated by a 1.0 in the cells where the same connection types are found), so the weighted connection type value in Table A can be included in the aptitude determination. As mentioned above, the age of each order can be used to affect the connection type determination. For example, in one mode, the connection type adjustment value is selected using the matrix in Table C for ages at threshold 1, 2, and 3. For ages at threshold 4 or above, the connection type can be established at 1.0 (even for unsupported connection types) and the corresponding weighted connection type value can be applied. While the "type" of the connection is used in some modalities, the connection speed can be determined and used with, or instead of, the type of connection. For example, connection speeds within certain specified ranges can be considered "compatible" (for example, 0-100kbps; 100-500kbps; 500-1000kbps, 1000-1500kbps, etc.). Some of the compatible variables discussed in this application can also be applied as weights to the adjustment of the compatibility and age calculation as described above.
[000170] In one embodiment, the player's language can be derived from the language acceptance header for HTTP request which can contain one or more languages with a q factor of preference. The scheduler can extract the most preferred language and pass this information on to the intermediary. In one embodiment, the weighted language value in Table A is set to 1.0 if the languages are the same or 0.0 if they are not. However, in one modality, the weighted language value can be applied even if the languages are different if the age is above a specified threshold (for example, if the age is at threshold 2 or above in Table B).
[000171] In one modality, a match can be made between two users with incompatible NAT types. For example, if the intermediary is having difficulty matching users of a particular MSI, after a specified period of time he can route connections through the 1051 retry service using the techniques described above. In this way, the 1051 repeat service acts as a pressure valve, allowing age compatibility to occur despite incompatible NAT types. The 1051 retry service can also be used in response to the detection of one or more failed combination attempts. In this embodiment, each compatibility request submitted by a mobile device can include an indication as to whether one or more unsuccessful compatibilities have previously been attempted.
[000172] Several additional combination criteria can be evaluated and provided a weight value as part of the compatibility adjustment determination including, by way of example and not limitation, an indication as to whether any of the users requesting compatibilities are friends. For example, intermediary 1510 can try to match any order on users who are "friends" by applying a "friends" weight to the match adjustment calculation. Similarly, friends of friends can also be weighted (for example, with 2 or more degrees of separation). Additionally, a player can rate other players in a particular game and the intermediary can rate those ratings by running a match (with a tendency to match a user with those players having relatively higher ratings and not match a user with players having low ratings ). In addition, a user's connection latency can be assessed (for example, using a simple ping operation) and used as part of the intermediation decision.
[000173] Yet another variable used to make players compatible may be the type of device. For example, intermediary 1510 may try to match players with similar device types (for example, iPads, iPods, iTouchs, iPhones, RIM Blackberries, etc.). Additional variables can include a user's leader rating, current position, current residence, age, gender, and collections of similar games that can be similarly assessed for compatibility determination (that is, in many cases that tend to favor compatibility between those users with similar criteria). Finally, parental controls can be evaluated by intermediary 1510 to ensure that users are only matched with appropriate MSIs and other users of the same age.
[000174] Brokerage service 111 can retrieve any of the above mentioned variables from one or more databases managed within data service 100 (see, for example, database 1920 described below with respect to figure 19). For example, a user's friend data can be accessed from a friend service database and other information, such as each user's age, gender, game collection, etc., can be accessed from one or plus other databases (for example, a user profile, a game database, a leader database, etc.). In one embodiment, all of the services described in this application are provided with access to the same central database (or group of databases) to store all of the different types of user / device data used to make intermediation decisions.
[000175] While several specific examples are provided above, it will be appreciated that the underlying principles of the invention are not limited to any particular set of variables to determine a level of suitability for compatibility. In one embodiment, application programmers who design applications to be managed in the system and method described in this application can specify their own set of compatibility criteria and / or to group orders using different MSI criteria.
[000176] Moving back to the method of figure 18, once the "adjustment" of compatibility between each pair was determined, in 1803, the pairs are classified by descending adjustment (for example, with the pairs having the most appropriate adjustment). high at the top of the list). In 1804, "matching sets" are seeded with those pairs that have the highest adjustment values above the specified threshold. As described above, the "threshold" value can be set to the normalized value of 1.0 shown above in Table A. In 1805, new prospective partners are added to the compatibility set having eigenvalues with one or all of the current members in the compatibility set above a specified threshold. For example, if a compatibility set was initially seeded with A and B, then C can be added to the compatibility set if the adjustment value of A-C and / or B-C is above the specified threshold. In one embodiment, if only one unique combination is above a threshold of a prospective part, then that part can be added to the compatibility set (that is, because, if necessary, that part will be able to communicate with all parts by a part with which it has an appropriate compatibility setting). Once one or more new parts are added to the compatibility set, if the combination size requirements have been met, determined in 1806, then the combination results are stored and reported in 1807 (for example, by updating the order table 1502 and transmitting notifications as described above). In one embodiment, a single compatibility request can represent multiple users (for example, when a compatibility request follows an invitation sequence as described below). In this case, size requirements are assessed based on the number of users represented by each compatibility request. If the size requirements have not been met, then the process returns by 1805 and a new part is added to the compatibility set (that is, a part that has a compatibility adjustment with one or more of the current members of the set above one specified threshold).
[000177] In 1808, combined orders are removed from the current set of orders that are processed by intermediary 1510. In 1809, the following seeded compatibility set is selected and the process returns up to 1804 for further compatibility. Although illustrated in figure 18 as a sequential process, it should be noted that multiple seed combination sets can be processed concurrently while still complying with the underlying principles of the invention.
[000178] Although described above as separate services, the intermediation service 111 and the invitation service 112 can operate together to connect P2P users. For example, in a modality, a first user can invite one or more friends to an online session and request a match with one or more additional users (for example, INVITE friend "Bob" and combine with 3 additional players from a video- multilayer game). In such a case, invitation service 112 may initially process the first user's invitation request to connect the first user and the first user's friend (s). The results of the invitation request (for example, a successful P2P connection) can then be reported back to the user's mobile device. The 111 brokerage service can then receive a compatibility request from the first user's mobile device (or, in one instance, directly from the invitation service or from the first user's friends) requesting additional players. In response, the intermediation service 111 can match one or more compatibility requests with the first user having the same MSI as the first user's request (as described above). The compatibility order can only include compatibility criteria for the first user or can include compatibility criteria for the first user and the friend of the first user (for example, NAT type, connection type, language, position, etc.). In one embodiment, if one or more of the friends of the first user cannot establish a direct P2P connection with another compatible user, the connection of the compatible user to friends of the first user can be established through the data processing device of the first user (for example, example, using the first user's mobile device as an intermediary connection server) and / or the retry service can be used to connect users (as described above).
[000179] In one modality, the first user can be initially matched with one or more users by the intermediation service (as described above) and then the first user can invite one or more friends to join the online session with the first user and compatible users. In this modality, both the user information and the information of the compatible users (for example, NAT / connection data, user IDs, push authenticators, etc.) can be exchanged with the invited users through the invitation service (as described above) . The underlying principles of the invention remain the same even if matching occurs first, followed by the invitation, or if the invitation occurs first, followed by compatibility. Applied Architecture with an Application Programming Interface for Collaborative Online Applications
[000180] As illustrated in figure 19, a modality of the invention is implemented within the context of a mobile device 120 having a predefined program architecture 1912 with an application programming interface ("API") 1910 to interrelate with one or more 1911 applications and a 1910 assistance API to communicate with a plurality of 1901-1903 network services. As shown in figure 19, network services 1901-1903 can be designed and / or managed by the same online data service 100 (although such a configuration is not required). 1911 applications such as P2P game applications and other types of collaborative online applications can be designed to access network services 1901-1903 through 1910 API by making calls to the 1910 API. The design of 1911 applications can be facilitated using a kit development program ("SDK") provided by the developer of the 1912 architecture and the network services 1901-1903. A more specific implementation of the 1912 architecture and 1910, 1913 APIs is described below with respect to figure 20.
[000181] As illustrated, each of the services can be provided with access to a 1920 database to store data used by the services. A particular example is the database 1512 used by the intermediation service 111 (described above). Other examples may include a leading database for storing leader data, a friend service database for storing friend status records, a profile database for storing user profile data, and a game database to store data related to online games. Any type of database can be used (for example, MySQL, Microsoft SQL, etc.) but in a particular mode, a key / value database, such as Berkley DB and / or MZBasic DB can be used. Databases can be expanded through a large number of mass storage devices (for example, hard drives) in a Storage Area Network (SAN) or other configuration.
[000182] Consequently, when a particular service processes and / or stores data as described above, the data may be stored within the 1920 database. Some services, however, may not use a database. For example, as described above, invitation service 112 can be implemented as a stateless service and, therefore, it may not be necessary to store data within a 1920 database (although such implementation is still possible according to the principles underlying the invention).
[000183] API 1913 can be designed to communicate and exchange information with network services 1901-1903 using any suitable network protocol stack including, for example, TCP / IP or UDP / IP at the network layer and HTTPS at the network layer. application. A protocol based on remote procedure call (RPC) - over HTTP or HTTPS, such as SOAP can be used and / or a Representational State Transfer (REST) protocol can be used. In addition, services can be implemented on any computing platform including, for example, Xserve or similar servers running Unix, Linux or an Apache program platform. In a particular modality, the platform includes Web objects implemented in Linux. Previous examples are provided for illustrative purposes only. The underlying principles of the invention are not limited to any particular mechanism for linking applications to services or any particular set of network protocols.
[000184] Figure 20 illustrates a more detailed program architecture including application programming interfaces (APIs) 2001a-b that can be implemented on the wireless device 120 in an embodiment of the invention. Although this modality is described within the context of a multiplayer 2000 game architecture, the underlying principles of the invention are not limited to a game implementation. For example, the program architecture shown in figure 20 can be used to support various collaborative applications that are not games (for example, collaborative conversation, collaborative audio with many participants / video, etc.).
[000185] In the architecture shown in figure 20, a game architecture 2000 is provided to support various attributes with many participants and P2P attributes described in this application. In one embodiment, the game architecture 2000 is designed to run on the operating system of the 2005 mobile device. For example, if the mobile device 120 is an iPhone, iPad, or iPod Touch, the 2005 operating system can be the iPhone OS, a mobile operating system designed by the assignee of this patent application.
[000186] The game architecture 2000 may include a public application programming interface (API) 2001b and a private or "secure" API 2001a. In one embodiment, a 2031 game central application designed to provide various attributes related to the game described in this application can make calls to both the public API 2001b and the private API 2001a, while other 2030 applications (for example, applications designed by third parties ) are provided with access to the public API 2001b only. For example, the designer of the mobile device 120 may wish to maintain certain API functions that involve potentially sensitive information outside of the public API 2001b to prevent abuse by external developers (for example, friend requests, friend lists, etc.). However, both the secure API 2001a and the public API 2001b can be merged into a single accessible API for all applications on the mobile device (ie, separation of the API into separate public and private components is not necessary to comply with the underlying principles of invention). The term "API 2001" is sometimes used below to refer to operations that can be found on any public API 2001b and / or private API 2001a.
[000187] A modality for the application of game center 2031 is described in the copending patent application entitled Systems and Methods for Providing a Game Center, Legal Registration No. 4860.P9127USP1, Serial No. 61 / 321.861, filed on April 7 of 2010, having the inventors Marcel Van Os and Mike Lampell (hereinafter "Central Game Patent Application"), who is assigned to the assignee of the present patent application and which is incorporated in this application by reference. In summary, the game center application 2031 includes a graphical game-centered user interface (GUI) for browsing multiplayer games; buying new games; retrieving information related to games (for example, leader information, achievements, friend information, etc.); contact with friends to play games; requesting game matches with other users; and invitation from specific users. Various other functions performed by the 2031 game center application are described in the Game Center Patent Application referred to above. Some functions of the game board can be provided by the game architecture 2000 and made accessible to other 2030 applications by the public API 2001b.
[000188] In one modality, API 2001 exposed by the game architecture 2000 simplifies the process of designing collaborative multiplayer games for the mobile device 120. Especially, in one modality, API 2001 allows developers to make a simple API call to invoke the relatively complex process of connecting users of a P2P multiplayer game session. For example, a simple API call such as INVITE (Player ID B, Bucket ID), can be invoked from API 2001 to initiate the detailed invitation sequence described above. Similarly, an API call, such as MATCH (Player ID A, Bucket ID) can be invoked from API 2001 to initiate the detailed intermediation sequence described above. The INVITE and MATCH functions are sometimes referred to generically in this order as "P2P Connection Functions". In one embodiment, the 2000 game architecture includes the program code needed to manage invitation and broker operations in response to these API calls (as described in more detail below). It should be noted that the actual API functions may have somewhat different data formats than those presented above, (although they may result in similar operations performed by the 2000 game architecture). The underlying principles of the invention are not limited to any particular format for specifying API functions.
[000189] Various other types of transactions related to the game and information can also be managed by the game architecture 2000 on behalf of the games center 2031 and other applications 2030. Some of this information is described in the Games Center Patent Application. By way of example and not limitation, this information may include "leader" information related to those users who achieved a high score for each game and information about "achievements" identifying users who completed certain achievements specific to the game. Each application developer can specify their own set of "achievements" for each 2030 game application (for example, levels completed 1-3; level 1 completed in less than 5 minutes; more than 50 deaths per level; dropped 20 flags; etc.).
[000190] Game architecture 2000 may also include program code for managing a user's friend data and for integrating friend data within the context of the 2031 game center and other 2030 game applications. For example, when the user selects a connection to a particular game within the 2031 game center, information related to each of the user's friends can be displayed for that game (for example, the ranking of friends on the leader board, the achievements of friends, the results when the user played the game with each of their friends, etc.). In one embodiment, API 2001 for game architecture 2000 includes functions for accessing friend data managed by a friend service, such as the one described in the patent application entitled Apparatus and Method for Efficiently Managing Data in a Social Networking Service, No. Legal Registration 4860. P9240Z, Serial No. 61 / 321,848, filed on April 7, 2010, with inventors Amol Pattekar, Jeremy Werner, Patrick Gates, and Andrew H. Vyrros (hereinafter "Friend Service Application"), who is assigned to the assignee of this application for patent and which is incorporated in this application by reference.
[000191] As illustrated in figure 20, in a modality, a 2020 game background program can interrelate the 2000 game architecture to a first set of 2050 services and a 2010 game services component can interrelate the game architecture 2000 to a second set of services 2051. By way of example, the first set of services 2050 may include the invitation service 112, broker service 111, and replay service 1051 described above and the friend service described in Friend Service Patent Application referred to above. Other services that can be accessed through the 2020 game background program include a leader board service (providing leader board data); a game service (providing statistics and other data related to each of the games and the ability to purchase the game); a user authentication service (to authenticate the user of the mobile device); and / or a user profile service (to store user profile data, such as user preferences). The second set of 2051 services accessed via the 2010 gaming services component may include the connection data exchange service (CDX) 110 and NAT traversal services 290-291 described above. Although illustrated as separate components in figure 20 for purposes of illustration, the game background program 2020 and the game services module 2010 can in fact be components of the game architecture 2000. In one embodiment, the background program of game 2020 and 2010 communicates with each of the 2050-2051 network services through a predefined API that, in one modality, is a private API (that is, not published to external developers).
[000192] In one embodiment, the 2020 game background program can communicate with the intermediation service 111, invitation service 112, and other 2050 services using the HTTPS protocol while the 2010 game services module can communicate with the CDX 110 service and NAT traversal services 290-291 using a relatively inconsequential protocol, such as UDP sockets. However, as previously mentioned, several other network protocols can be employed while still complying with the underlying principles of the invention.
[000193] In addition, as illustrated in figure 20, the 2020 game background program can receive 2052 push notifications generated by certain 2052 services (for example, the invitation service and brokerage service) while other types of 2053 push notifications can be received directly by the game center (for example, friend service notifications, such as new friend requests). In one embodiment, these 2053 push notifications are provided directly to the 2031 game center to ensure that a user's sensitive data will not become accessible to 2030 applications designed by external application developers.
[000194] Returned to the game invitation examples shown above in figure 11, when a 2030 application on mobile device A makes an invitation call to API 2001b of game architecture 2000 to invite a user of mobile device B (for example, INVITE (Player ID B, Game / Bucket ID)), game architecture 2000 can pass the invitation request to the 2020 game background program on the mobile device A. The 2020 game background program can then communicate with invitation service 112 to submit the invitation request. The invitation service 112 can then use the push notification service 1050 (as described above) to forward the invitation to the 2020 mobile device game background program B. The mobile device game 2020 background program can then communicate with the mobile device B game architecture 2000 to determine if the game the invitation was sent to is installed on the mobile device B. In that case then the game architecture 2000 can launch the 2030 application and / or generate a notification visual of the invitation. If the application is not installed, then the game architecture 2000 can cause a visual notification of the invitation to the user of the mobile device B with an offer to buy the game (for example, via the 2031 game center GUI). Alternatively, visual notification can be generated by a background push notification program running on mobile device 120 (not shown). If the user of mobile device B buys the game, the invitation sequence can continue after purchase. If the user of the mobile device B accepts the invitation request, then the game architecture 2000 of the mobile device B can pass the invitation request to its 2020 game background program which can then respond to the invitation service 112.
[000195] Remember that in figure 11, the compatibility check 1106 determines that the NAT types of mobile devices A and B are compatible. Thus, in 1108, the mobile device A game 2020 background program can receive acceptance from mobile device B (for example, via push notification in the example) and, in one modality, passes acceptance to the 2000 game architecture. At this stage, the game architecture 2000 of mobile device A can notify the 2030 request application that mobile device B has accepted (via API 2001) or can wait to notify the 2030 request application until the devices have been successfully connected . In any case, the game architecture 2000 can pass a connection request to the game services module 2010 which, in one mode, can initiate a connection data exchange with the mobile device B. Especially, the game services module it can transmit connection data from mobile device A to mobile device B using the CDX 110 service (see, for example, Transactions 1111 and 1112 in figure 11). As described above, this communication can be implemented as a UDP connection using a secure "input" data structure.
[000196] Remember that in figure 12, if the compatibility check 1106 determines which types of NAT of mobile devices A and B are not compatible then the retry service 1051 can be used to provide a connection between the devices. Consequently, the game background program 2020 from mobile device B can receive a retry response 1203 from the invitation service (shown in figure 12) and the game background program 2020 from mobile device A can receive a retry response 1205 of the invitation service (via push notification service 1050). The 2020 game background programs on mobile devices A and B can communicate with the replay service at 1206 and 1207 to retrieve configuration data. In 1210, the 2020 game background program from mobile device B receives repeat update data from mobile device A, and in 1213, the 2020 game background program from mobile device A receives repeat update data from device A mobile B.
[000197] The final result of the processes shown in figures 11 and 12 is that the mobile devices A and B have established a connection with each other (a direct P2P connection or a repeat connection). In one embodiment, to detect a successful connection, game architecture 2000 can notify the 2030 application that requested the connection using an API call (for example, CONNECTED (Player ID A, Player B ID)). Mobile devices A and B can then play the specified game or other collaborative 2030 application using the established connection.
[000198] Thus, in response to the relatively simply call from API 2001 (for example, INVITE from Player B ID, Game / Bucket ID), a complex series of transactions can be managed by the game architecture 2000 to establish a connection P2P or one of repetition between mobile devices A and B. In one embodiment, the game architecture 2000 performs the sequence of operations to connect mobile devices A and B, and then provides the results to the 2030 request application, thereby leaving the details of the API call transparent to the application designer. As such, the application designer must not understand how to connect mobile devices A and B on the network, or perform various other functions necessary to allow communication between devices, thereby simplifying the application design process.
[000199] In a similar manner, game architecture 2000 can establish a combination between mobile device A and other participants using the intermediation service 111 as described above with respect to figure 2a-b. In this example, the 2030 application can make a simple call to API 2001, such as MATCH (Player ID A, Game / Package ID). In response, the 2000 gaming architecture can direct connection and correspondence data exchange operations. When the matching operations and / or P2P connections are complete, the game architecture 2000 provides the results back to the 2030 application.
[000200] For example, in figure 2b, game architecture 2000 can use the game services module 2010 to communicate with the connection data exchange service (CDX) 110 and NAT traversal services 290-291 and you can use the game background program to communicate with the 111 intermediation service. Once a match has been made, the game device 2020 background program on mobile device A receives Entry A at 229 and the architecture of game 2000 uses this information to implement a connection data exchange through the game services module 2010. For example, at 232, it can request its own connection data via NAT 290 traversal service and then can exchange its connection data in 233-234 through the CDX 110 service. In 237 and 240, the game services module 2010 of mobile device A receives connection data from mobile devices B and C, respectively. After these exchanges, the game services module 2010 establishes P2P connections at 241 and the game architecture 2000 notifies the 2030 application that the connection process is complete using an API notification (for example, MATCH COMPLETE (Player ID B, Player ID C)). The application can then run using the established P2P connection.
[000201] In some modalities, they can give the user the option of playing a game with other friends who are currently registered as "online". In this case, the notification that certain friends are online can be provided via push notifications 2052 or push notifications 2053 (received directly by the game center 2031). The 2031 game center and / or 2030 applications can then provide notifications to the user and provide the user with the option to play with one or more selected online friends. It should be noted, however, that the invitation sequence described in this application will work even if online notifications are provided. In one embodiment, the user's online status can be monitored by a service accessible by the 2020 game background program (for example, by the aforementioned friend service or by a separate "presence" service).
[000202] A game architecture modality 2000 provides for an invitation / intermediary operation combination in which a user can invite one or more friends to play a game with a group of unknown compatible participants. For example, if a game requires 4 players and a first user invites a second user to play the game, then the invitation service 112 can initially connect the first user and second user and the broker service 111 can then match the first user and second user with two (or more) other players. In this modality, the game architecture 2000 can initially perform the invitation sequences described above to connect the first user and the second user. In one modality, once the first user and the second user have been successfully connected, the game architecture 2000 can implement the intermediation sequences to identify and connect with other users. As mentioned above, in one modality, the compatibility criteria applied by the intermediation service can include both the first and the second user (for example, NAT types, connection types, language, etc., for both the first and the second user. ). Alternatively, the criteria of one of the two users can be assessed to make the decision to match.
[000203] Once all of the users are connected, the game architecture 2000 can provide the connection results to the 2030 application that requested the connection via API 2001. Again, in response to a relatively simple API call from an application 2030, game architecture 2000 establishes the group of complex transactions to connect each of the devices. Once the devices have been successfully connected, the game architecture 2000 provides the results back to the 2030 request application.
[000204] As illustrated in figure 20, the game architecture 2000 can include a temporary communication storage 2003 to temporarily store the communication between the user and other game participants. Communication can include, for example, text, audio and / or video communication. The 2000 game architecture can establish the 2003 temporary storage based on the requirements of each 2030 application. For example, a relatively larger 2003 temporary storage may be required for audio / video communication over a slow network connection. In one embodiment, each 2030 application can make an explicit request to establish a temporary communication storage of a certain size via API 2001 (for example, using a BUFFER command (size)). Alternatively, the game architecture 2000 can automatically create temporary storage based on the communication requirements of each application. For example, the 2000 game architecture may select a particular size of temporary stores based on whether text, audio, and / or video needs to be supported.
[000205] In one embodiment, the temporary communication storage 2003 can temporarily store communication flows before all P2P connections have been established between users. For example, after invitation service 112 or broker service 111 identifies each user but before the CDX 110 service has completed connection data exchange operations, each user can be notified of other game participants in the process of being connected. At this stage, the user of the mobile device 120 can transmit text, audio and / or video communication streams to other participants. The 2000 game architecture will store the communication flows within the 2003 communication temporary storage of those participants who are not yet connected. The 2000 game architecture can then transmit the text, audio and / or video from the 2003 temporary storage as the connection of each device is completed.
[000206] In one embodiment, the 2020 game background program includes a 2021 cache to omit persistent data on each of the 2050 services to reduce network traffic. For example, the user's friend list, leaderboard data, achievement data, presence data, and profile data can be stored in the 2021 cache as specified by a cache management policy. In one embodiment, the cache management policy is governed by each individual service in which the data is stored. Consequently, for different services, different cache management policies can be applied to the 2021 cache. In addition, because the cache management policy is managed by the services, it can be modified dynamically based on the current network and / or server load conditions. . For example, during time periods when a service is heavily loaded (for example, Christmas, new product release day, etc.), the service can dynamically specify a cache management policy with relatively infrequent cache updates ( for example, updates every 12 hours). On the other hand, during periods of time when a service is not heavily loaded, the service may specify a cache policy with more frequent cache updates (for example, it updates every% hour, hour, 2 hours, etc.).
[000207] In one embodiment, the cache management policy is specified using a time to live (TTL) value of certain data records stored in the 2021 cache. When a data record has been stored in the cache in addition to its value of TTL, then that data is considered "aged" and a local order on that data can be shipped directly to the service associated with that data. In one embodiment, the order includes an ID code that identifies a current version of the data. If the ID code matches the service ID code, then the data is still valid and does not need to be updated. A response can then be sent back from the service indicating that the data in the cache is current and the TTL value of the data record can be reset.
[000208] In addition to using a cache management policy as described above, in one embodiment, cache updates for certain types of data can be forwarded to the mobile device using the push notification service 1050. For example, modifications to the list of a user's friends or the current online status of the user's friends can be dynamically forwarded to the user's mobile device 120. The push notification can be received by the 2020 game background program which can then update the 2021 cache to include the portion relevant data forwarded by the service (that is, an update of all data in the cache associated with that service may not be required). On the other hand, some push notifications can instruct the 2020 game background program to overwrite the entire contents of the cache (or at least the portion of the cache associated with the service that performs the push).
[000209] Those services that use the push to update the 2021 cache can choose relatively high TTL values (and / or may not establish TTL values) because they have the ability to forward notifications to update data stored in the 2021 cache. , each service specifies the group of events that can trigger a push notification cache update. For example, cache update events can include a change in a friend's online status, a new friend request, an acceptance of a friend request, a friend operation, an indication that a friend is playing a particular game, a game achievement achieved by a friend, an update to the top 10 of a particular leader board, or any other event deemed to be of sufficient importance to warrant a cache update. Using push notifications to update the 2021 cache in this way can reduce the network and service load because, with push updates, periodic polling between the mobile device and the service is not required.
[000210] A game architecture modality 2000 only formats data presented to the end user based on the user's country and / or geographic position. For example, values such as current date, time and monetary values can be displayed differently for users in different countries and positions. By way of example, in the United States the date format can be [day of the month, year] (for example, April 25, 2010) whereas in other countries, the date format can be [month of the day, year] ] (e.g. April 25, 2010). Similarly, when representing time in the USA and some other countries, the designation AM / PM can be used and two periods can be used between hours and minutes (for example, 3:00 PM). On the other hand, many other countries do not use the designation AM / PM and / or use a comma between hours and minutes (for example, 15.00). As another example, many parts of the world use the metric system while some parts of the world do not (for example, the United States). It should be noted that these are simply illustrative examples that can be used by certain embodiments of the invention. The underlying principles of the invention are not limited to any particular set of data formats.
[000211] In one embodiment, these different data formats can be selected by displaying leaderboard data, achievement data, friend data, and / or any other data processed by the 2000 game architecture. The 2000 game architecture can determine the user's country and / or geographic position in various ways. For example, in one embodiment, this information is simply provided in the user's profile data and / or can be determined based on the user's cellular service provider. The user's position can also be determined using, for example, tracking with Global Positioning System (GPS).
[000212] Other types of data formatting that are unrelated to geographic position and / or country can also be managed by the game architecture 2000. For example, when displaying data from the leader board, it is important to know whether the highest score bottom should place the user above or at the bottom of the leader board. For some games (for example, golf, track, running, skiing, etc.), a lower number indicates better performance whereas in other games (for example, football, baseball, etc.), a higher number indicates better performance. Thus, in one modality, the 2030 application specifies the type of score that will be used via API 2001 (for example, "ascending" or "descending"). The 2000 game architecture can then use the appropriate set of markers and formatting to display the score.
[000213] A game architecture mode 2000 also filters user data based on the relationship between the user and the user's friends. For example, one embodiment of the invention allows for a "detailed" view, a "friends" view, and a "public" view. In one embodiment, the detailed view is available to the user who owns the data (that is, the user's personal information); the friends' view is available to the user's friends; and the public view is available to all other users.
[000214] For example, the public view may simply include a "pseudonym" name associated with each user, the games played by the pseudonym and associated scores, and the dates / times on which the games were played. This information can be used by the 2000 gaming architecture to propagate a public leader board that can then be viewed via the 2031 gaming hub.
[000215] The view of the friends can include all the information of the overview as well as any additional information to be shared among the friends of the user including, for example, the games owned by the user; the games played by the user; the user's achievements and scores; how many friends the user has; the identification of those friends; URL identifying the user's avatars, and / or the user's online status, to name some. In one embodiment, the "friends" view provides a pre-configured set of information to be shared with friends, but the end user can adjust this pre-configured configuration and specify in particular the types of information to be shared by each individual friend. or groups of friends (for example, employees, family members, college / high school friends, etc.).
[000216] The "detailed" view can include all information from the "friend" and "public" views as well as any other information managed by various 2050 services on behalf of the end user. By way of example, this can include all of the user's profile data; the user's Universally Unique Identifier ("UUID") (sometimes referred to in this application as "Player ID"); Player's name; pseudonym names; number of games and the identity of the games; the user's friends; all user achievements, etc.
[000217] In some circumstances, a 2030 application may only require a small amount of information related to each user, such as the Player ID of each user. For example, in a modality, when a combination is requested, the 2000 game architecture can only initially require each player's ID. As the compatibilities are made by the intermediation service (see above), the game architecture that 2000 can determine if any of the compatible users are friends (for example, via communication with the friend service and / or by consulting the local data of the friend of the user). In that case then the game architecture 2000 can retrieve additional user data and provide that data to any combined friend. In this way, the game architecture 2000 filters information based on the individuality of the users and the relationship between each of the users.
[000218] In one embodiment, the game architecture 2000 initially provides a public view between a first user and a second user if the two users do not have a friendly relationship. However, in one embodiment, the 2000 game architecture allows the first user to send a friend request to the second user (for example, using the second user's alias). If the friend request is accepted, then the game architecture 2000 will provide additional information to each of the users (for example, the pre-configured "friend" view). Different API Modalities
[000219] The API implemented in a modality, is an interface implemented by a program component (hereinafter "program component for API implementation") that allows a different program component (hereinafter "API calling program component" ") access and use one or more functions, methods, procedures, data structures, and / or other services provided by the program component for implementing the API. For example, an API allows a developer of an API calling program component (who may be an external developer) to leverage specified attributes provided by a program component for implementing the API. There may be one program component of the API call, or there may be more than one such program component. An API can be a source code interface that a computer system or program library provides in order to support requests for services from a program application. An API can be specified for a programming language that can be interpreted or compiled when an application is built, rather than an explicit low-level description of how data is displayed in memory.
[000220] The API defines the language and parameters that API calling program components use by accessing and using the specified attributes of the program component for implementing the API. For example, an API calling program component accesses the specified attributes of the program component for implementing the API through one or more API calls (sometimes referred to as function or method calls) displayed by the API. The program component for implementing the API can return a value through the API in response to an API call from an API calling program component. While the API defines the syntax and result of an API call (for example, how to invoke the API call and what the API call does), the API typically does not reveal how the API call performs the function specified by the call API. Various function calls or messages are transferred via one or more application programming interfaces between the calling program (API calling program component) and a program component for implementing the API. The transfer of function calls or messages may include sending, initiating, invoking, calling, receiving, returning or responding to function calls or messages. Therefore, an API call program component can transfer a call and a program component for API implementation can transfer a call.
[000221] By way of example, the program component for implementing API 2010 and the calling program component of the API can be an operating system, a library, a device driver, an API, an application program, or other program module (it should be understood that the program component for implementing the API and the program component for calling the API can be the same or different type of the program module with each other). The API calling program component can be a local program component (that is, in the same data processing system as the program component for implementing the API) or a remote program component (that is, in a different data processing as the program component for implementing the API) that communicates with the program component for implementing the API through the API over a network. It should be understood that a program component for API implementation can also act as an API calling program component (that is, it can make API calls to an API exposed by a different program component for API implementation) and a API calling program component can also act as a program component for implementing the API by implementing an API that is exposed to a different program calling API component.
[000222] The API may allow multiple calling of API program components written in different programming languages to communicate with the program component for implementing the API (in this way, the API may include attributes of translating calls and returns between the program component for API implementation and the API calling program component); however the API can be implemented in terms of a specific programming language.
[000223] Figure 21 illustrates a modality of an API architecture that includes a program component for implementing API 2110 (for example, an operating system, a library, a device driver, an API, an application program, or other. program module) that implements API 2120. API 2120 specifies one or more functions, methods, classes, objects, protocols, data structures, formats and / or other attributes of the program component for implementing the API that can be used by API 2130 calling program component. API 2120 can specify at least one calling convention that specifies how a function in the API implementation program component receives parameters from the API calling program component and how the function returns a result to the API calling program component. The API 2130 calling program component (for example, an operating system, library, device driver, API, application program, or other program module), makes API calls through API 2120 to access and use the attributes the program component for implementing API 2110 that are specified by API 2120. The program component for implementing API 2110 can return a value through API 2120 to the API 2130 calling program component in response to an API call.
[000224] It will be appreciated that the program component for implementing API 2110 may include additional functions, methods, classes, data structures, and / or other attributes that are not specified by API 2120 and are not available for the program component of API 2130 call. It should be understood that the API 2130 calling program component can be on the same system as the API 2110 implementation program component or can be located remotely and access the API 2110 implementation program component using API 2120 over a network. While figure 21 illustrates a single API 2130 calling program component interacting with API 2120, it should be understood that other API calling program components, which can be written in different languages (or in the same language) than the API 2130 calling program component, you can use API 2120.
[000225] The program component for implementing API 2110, API 2120, and the calling program component of API 2130 can be stored in a machine-readable medium, which includes any mechanism for storing the information in a readable form by a machine (for example, a computer or other data processing system). For example, a machine-readable medium includes magnetic disks, optical disks, random access memory; read-only memory, flash memory devices, etc.
[000226] In figure 22 ("Program Stack"), an exemplary modality, applications can make calls to Services 1 or 2 using various Service APIs and to the Operating System (OS) using various OS APIs. Services 1 and 2 can make calls to the OS using various OS APIs.
[000227] Note that Service 2 has two APIs, one of which (API 1 of Service 2) receives calls and returns values to Application 1 and the other (API 2 of Service 2) receives calls and returns values to Application 2. The service 1 (which can be, for example, a program library) makes calls and receives API 1 return values from the OS, and Service 2 (which can be, for example, a program library) calls and receives return values both of API 1 of the OS as well as of API 2 of the OS. Application 2 makes calls and receives API 2 returned values from the OS. Exemplary Data Processing Devices
[000228] Figure 23 is a block diagram illustrating an exemplary computer system that can be used in some embodiments of the invention. It should be understood that while figure 23 illustrates various components of a computer system, it is not intended to represent any particular architecture or way of interconnecting the components as such details are not suitable for the present invention. It will be appreciated that other computer systems that have fewer components or more components can also be used with the present invention.
[000229] As illustrated in figure 23, the computer system 2300, which is a form of a data processing system, includes the 2350 bus (s) which is coupled to the 2320 processing system, 2325 power supply, 2330 memory , and 2340 non-volatile memory (for example, a hard disk drive, flash memory, Phase Shift Memory (PCM), etc.). The 2350 bus (s) can be connected to each other by various bridges, controllers, and / or adapters as are well known in the art. The processing system 2320 can retrieve instruction (s) from memory 2330 and / or non-volatile memory 2340, and execute instructions to perform operations as described above. The 2350 bus interconnects the above components together and also interconnects those components to the optional 2360 platform, the 2370 monitor controller & 2370 monitor device, 2380 Input / Output devices (for example, NIC (Network Interface Card), a control optional cursor (for example, mouse, touchscreen, touchpad, etc.), keyboard, etc.) and 2390 optional wireless transceiver (s) (for example, Bluetooth, WiFi, Infrared, etc.).
[000230] Figure 24 is a block diagram illustrating an exemplary data processing system that can be used in some embodiments of the invention. For example, the 2400 data processing system can be a portable computer, a personal digital assistant (PDA), a cell phone, a portable game system, a portable media player, a tablet, or a handheld computing device that can include a cell phone, media player and / or game system. As another example, the data processing system 2400 can be a network computer or a processing device inserted into another device.
[000231] According to an embodiment of the invention, the exemplary architecture of the 2400 data processing system can be used for the mobile devices described above. The 2400 data processing system includes the 2420 processing system, which may include one or more microprocessors and / or a system on an integrated circuit. The 2420 processing system is coupled with a 2410 memory, a 2425 power supply (which includes one or more batteries), a 2440 audio input / output, a 2460 monitor controller and monitor device, optional 2450 input / output device, input (s) 2470, and 2430 wireless transceiver (s). It will be appreciated that additional components, not shown in Figure 24, can also be a part of the 2400 data processing system in certain embodiments of the invention, and in certain modalities of the invention less components than shown in figure 24 can be used. In addition, it will be appreciated that one or more busbars, not shown in figure 24, can be used to interconnect various components as is well known in the art.
[000232] The 2410 memory can store data and / or programs for execution by the 2400 data processing system. The 2440 audio input / output can include a microphone and / or a speaker, for example, for playing music and / or providing telephony functionality via speaker and microphone. The monitor controller and the 2460 monitor device can include a graphical user interface (GUI). Wireless transceivers (for example, RF) 2430 (for example, a WiFi transceiver, an infrared transceiver, a Bluetooth transceiver, a wireless cell phone transceiver, etc.) can be used to communicate with other data processing systems Dice. One or more 2470 input devices allow a user to provide input to the system. These input devices can be a keyboard, keyboard, touch panel, multitouch panel, etc. Another optional 2450 input / output can be a platform connector.
[000233] The modalities of the invention can include several steps as presented above. The steps can be incorporated into machine-executable instructions that cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps can be performed by specific machinery components containing the logic by machinery to carry out the steps, or by any combination of programmed computer components and adapted machinery components.
[000234] The elements of the present invention can also be provided as a machine-readable means for storing machine-executable program code. Machine-readable media may include, but is not limited to, floppy disks, optical discs, CD-ROMs, and magneto-optical discs, ROMs, random access memories, EPROMs, EEPROMs, magnetic or optical cards, or other media / machine-readable media suitable for storing electronic program code.
[000235] Throughout the preceding description, for the sake of explanation, numerous specific details have been presented in order to provide a complete understanding of the invention. It will be evident, however, to one skilled in the art that the invention can be practiced without some of these specific details. For example, it will be readily apparent to those skilled in the art that the functional modules and methods described in this application can be implemented as a program, machinery or any combination thereof. In addition, although the modalities of the invention are described in this application within the context of a mobile computing environment (i.e., using mobile devices 120-123; 601-603), the underlying principles of the invention are not limited to a mobile computing implementation. Virtually any type of customer or peer data processing device can be used in some modalities including, for example, desktop computers or workstation computers. Consequently, the scope and spirit of the invention must be judged on the claims that follow.

权利要求:
Claims (16)
[0001]
1. Method implemented by computer to establish point-to-point communication ("P2P") between mobile devices, characterized by the fact that it comprises the steps of: receiving (1601, 1603) a plurality of compatibility requests from a plurality of mobile devices ( 120-122), each of the compatibility requests including application data indicating a particular application for which compatibility is being requested and also including network configuration data indicating a network configuration for each of the plurality of mobile devices (1502 , 1503); determine (1802) compatibility adjustments for groups of the plurality of mobile devices, compatibility adjustments based, at least in part, on the network configuration data of the mobile devices; and to generate (1807) compatibility of two or more mobile devices based on both the application data and the compatibility adjustments determined for the mobile devices; determine the age of each of the compatibility requests; and adjust the compatibility setting for possible compatibility between two or more mobile devices based on the age of each of the compatibility requests.
[0002]
2. Method, according to claim 1, characterized by the fact that determining the compatibility adjustment includes determining the compatibility between the network configurations of two or more mobile devices that submit the compatibility requests.
[0003]
3. Method, according to claim 2, characterized by the fact that determining network configuration compatibility comprises determining the types of network address translation ("NAT") device used by two or more mobile devices, the method still comprises the attempt to generate compatibility between mobile devices having types of NAT devices that are capable of establishing direct P2P communication channels.
[0004]
4. Method, according to claim 1, characterized by the fact that the compatibility adjustment is based on the connection types of each of the mobile devices, the method also comprises the attempt to generate compatibility between mobile devices having similar connection types .
[0005]
5. Method according to claim 1, characterized by the fact that the connection types include WiFi connections, third generation cellular connections ("3G") and Edge cellular connections.
[0006]
6. Method, according to claim 1, characterized by the fact that the compatibility adjustment is based on one or more languages for which the mobile devices are configured, the method still comprises the attempt to generate compatibility between mobile devices having a or more languages in common.
[0007]
7. Method, according to claim 1, characterized by the fact that compatibility requests still include configuration variables for each application, the method still comprises ensuring compatibility for mobile devices based, in part, on configuration variables.
[0008]
8. Method, according to claim 7, characterized by the fact that the configuration variables include a level of experience for the application and / or a sub-application of the application.
[0009]
9. Method, according to claim 1, characterized by the fact that adjust comprises continuing to increase the compatibility adjustment as the age increases above one or more thresholds.
[0010]
10. Method, according to claim 1, characterized by the fact that generating compatibility still comprises: grouping (1605) compatibility requests in compatibility groups based on the application data; determine (1606) compatibility adjustments for compatibility requests within each compatibility group; and generate compatibility for mobile devices with each compatibility group based on a determined compatibility setting.
[0011]
11. Method, according to claim 1, characterized by the fact that generating compatibility still comprises: grouping (1605) compatibility requests in compatibility groups based on the application data; determine (1606) compatibility adjustments for pairs of compatibility requests within each compatibility set; seeding (1804) each of a plurality of compatibility sets with pairs of compatibility requests that have a compatibility adjustment above a specified threshold; add (1805) compatibility requests to each compatibility set; retain additional compatibility requests in each compatibility set if the total number of compatibility adjustments in the compatibility set are below the specified threshold.
[0012]
12. Method, according to claim 11, characterized by the fact that it still comprises: continue adding compatibility sets until the compatibility size requirements have been satisfied.
[0013]
13. Method, according to claim 1, characterized by the fact that compatibility requests include NAT traversal / connection data associated with each of the mobile devices, the method further comprises: transmitting (1608) a notification to the set of compatible mobile devices that a compatibility has been made, the notification sent to each mobile device including NAT traversal / connection data needed to connect to one or more of the other mobile devices included in the compatibility.
[0014]
14. Method according to claim 13, characterized by the fact that NAT traversal / connection data includes a public IP address and port for each of the mobile devices.
[0015]
15. Machine-readable medium, characterized by the fact that it has program code stored in it which, when executed by a computational device, causes the computational device to execute a method as defined in any one of claims 1 to 14.
[0016]
16. Computational device, characterized by the fact that it comprises a memory for storing program code and a processor for processing the program code to execute a method as defined in any one of claims 1 to 14.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012025586B1|2021-02-09|computer-implemented method to establish point-to-point | communication between mobile devices, machine readable medium and computing device

---

US9319467B2|2016-04-19|Apparatus and method for efficiently and securely exchanging connection data

---

US9130820B2|2015-09-08|Application programming interface, system, and method for collaborative online applications

---

US9654551B2|2017-05-16|Apparatus and method for inviting users to online sessions

---

CA2794032C|2015-04-07|Apparatus and method for establishing and utilizing backup communication channels

---

JP5711849B2|2015-05-07|Apparatus and method for managing peer-to-peer connections between different service providers

---

BR112012025350B1|2021-09-21|COMPUTER IMPLEMENTED METHOD TO ESTABLISH P2P COMMUNICATION BETWEEN MOBILE DEVICES, MACHINE-READABLE MEDIUM AND COMPUTER DEVICE

同族专利:

---

公开号 | 公开日

---

EP2540059A1|2013-01-02|

---

DE112010005474T5|2013-01-31|

---

KR101408490B1|2014-06-17|

---

US9118690B2|2015-08-25|

---

GB201218272D0|2012-11-28|

---

AU2010350745A1|2012-10-25|

---

GB2491785A|2012-12-12|

---

JP5543663B2|2014-07-09|

---

KR20130006676A|2013-01-17|

---

CN102215249A|2011-10-12|

---

US8341207B2|2012-12-25|

---

EP2540059B1|2014-02-12|

---

MX2012011617A|2012-11-30|

---

US20120011189A1|2012-01-12|

---

ES2463099T3|2014-05-27|

---

WO2011126507A1|2011-10-13|

---

JP2013528980A|2013-07-11|

---

AU2010350745B2|2014-10-09|

---

BR112012025586A2|2016-06-21|

---

US20130110938A1|2013-05-02|

---

CN102215249B|2014-02-26|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

CN100531207C|2005-12-01|2009-08-19|华为技术有限公司|Method and apparatus for matching service type of point-to-point protocol on ethernet|

---

JP2007301045A|2006-05-09|2007-11-22|Aruze Corp|Matching server and game system|

---

EP1914973B1|2006-10-16|2014-02-26|Motorola Mobility LLC|System and method to provide combinational services to anonymous callers|

---

JP4425257B2|2006-11-08|2010-03-03|株式会社ソニー・コンピュータエンタテインメント|COMMUNICATION DEVICE, COMMUNICATION CONTROL METHOD, AND COMMUNICATION CONTROL PROGRAM|

---

US9420047B2|2007-02-19|2016-08-16|Telefonaktiebolaget Lm Ericsson |Method and apparatus for enabling user services in communication network|

---

US7808909B2|2007-10-01|2010-10-05|Samsung Electronics Co., Ltd.|Method and a system for matching between network nodes|

---

KR100932077B1|2007-12-12|2009-12-15|한국전자통신연구원|Code interpretation method for providing multiple services using one code|

---

EP2258075B1|2008-03-11|2018-02-28|Flybits Inc.|Method, apparatus and system for social networking|

---

CN101299772B|2008-06-04|2011-05-11|中兴通讯股份有限公司|System and method for processing network address conversion preferable regulation|

---

KR20100000648A|2008-06-25|2010-01-06|삼성전자주식회사|Method and apparatus for providing a network output service using a mobile communication device|

---

JP2010021863A|2008-07-11|2010-01-28|Sharp Corp|Network system, communication terminal, communication method, and communication program|

---

US8060626B2|2008-09-22|2011-11-15|Sony Computer Entertainment America Llc.|Method for host selection based on discovered NAT type|

---

US8566531B2|2009-08-21|2013-10-22|Google Inc.|System and method of selectively caching information based on the interarrival time of requests for the same information|US8590002B1|2006-11-29|2013-11-19|Mcafee Inc.|System, method and computer program product for maintaining a confidentiality of data on a network|

---

US8621008B2|2007-04-26|2013-12-31|Mcafee, Inc.|System, method and computer program product for performing an action based on an aspect of an electronic mail message thread|

---

US8199965B1|2007-08-17|2012-06-12|Mcafee, Inc.|System, method, and computer program product for preventing image-related data loss|

---

US20130276061A1|2007-09-05|2013-10-17|Gopi Krishna Chebiyyam|System, method, and computer program product for preventing access to data with respect to a data access attempt associated with a remote data sharing session|

---

US8262472B2|2007-09-21|2012-09-11|Microsoft Corporation|Comprehensive single page view of user's gaming achievements|

---

US8979647B2|2007-10-26|2015-03-17|Microsoft Technology Licensing, Llc|Method of providing player status and ability to join games|

---

US8197313B2|2007-10-29|2012-06-12|Microsoft Corporation|User to user game referrals|

---

US8893285B2|2008-03-14|2014-11-18|Mcafee, Inc.|Securing data using integrated host-based data loss agent with encryption detection|

---

US8353053B1|2008-04-14|2013-01-08|Mcafee, Inc.|Computer program product and method for permanently storing data based on whether a device is protected with an encryption mechanism and whether data in a data structure requires encryption|

---

US9077684B1|2008-08-06|2015-07-07|Mcafee, Inc.|System, method, and computer program product for determining whether an electronic mail message is compliant with an etiquette policy|

---

US9614905B2|2009-10-20|2017-04-04|Avaya Inc.|Determination of persona information availability and delivery on peer-to-peer networks|

---

US8734255B2|2010-04-07|2014-05-27|Apple Inc.|Methods and systems for providing a game center having player specific options and statistics|

---

US8438294B2|2010-04-07|2013-05-07|Apple Inc.|Application programming interface, system, and method for collaborative online applications|

---

US8924304B2|2010-06-04|2014-12-30|Apple Inc.|Methods for using unique identifiers to identify systems in collaborative interaction in a mesh network|

---

US8606884B2|2010-09-21|2013-12-10|Taesung Kim|System and method for web hosting behind NATs|

---

WO2012046390A1|2010-10-07|2012-04-12|パナソニック株式会社|Communication apparatus, communication method, integrated circuit, and program|

---

KR20120081368A|2011-01-11|2012-07-19|주식회사 엔씨소프트|Method of game invitation with chatting window in mobile platform|

---

US8849900B2|2011-03-04|2014-09-30|Telcordia Technologies, Inc.|Method and system supporting mobile coalitions|

---

US8348752B2|2011-05-02|2013-01-08|At&T Intellectual Property I, Lp|Method and apparatus for managing a gaming application|

---

US9477734B2|2011-05-10|2016-10-25|Microsoft Technology Licensing, Llc|Data synch notification using a notification gateway|

---

US8341223B1|2011-06-07|2012-12-25|Banjo, Inc.|Method for relevant content discovery|

---

CN102546105A|2011-12-28|2012-07-04|深圳市新为软件有限公司|Method and device for network resource transmission|

---

US8782038B2|2012-04-20|2014-07-15|Eharmony, Inc.|Systems and methods for online compatibility matching and ranking|

---

US8844771B2|2012-07-31|2014-09-30|Piranha Plastics, Llc|Hemi-toroidal fluid pump|

---

CN102904882B|2012-09-24|2018-08-10|南京中兴新软件有限责任公司|The retransmission method and device of random call|

---

US9652525B2|2012-10-02|2017-05-16|Banjo, Inc.|Dynamic event detection system and method|

---

US9817997B2|2014-12-18|2017-11-14|Banjo, Inc.|User-generated content permissions status analysis system and method|

---

US10678815B2|2012-10-02|2020-06-09|Banjo, Inc.|Dynamic event detection system and method|

---

US10360352B2|2012-10-02|2019-07-23|Banjo, Inc.|System and method for event-based vehicle operation|

---

US9934368B2|2012-10-02|2018-04-03|Banjo, Inc.|User-generated content permissions status analysis system and method|

---

WO2014076578A2|2012-11-12|2014-05-22|Calgary Scientific Inc.|Framework to notify and invite users to join a collaborative session|

---

CN110380980A|2013-02-22|2019-10-25|英特尔Ip公司|System and method for accessing network selection and flow routing|

---

US9363165B2|2013-03-11|2016-06-07|Qualcomm Incorporated|Enhanced call control for directing a content path over multiple connections|

---

US9043329B1|2013-12-19|2015-05-26|Banjo, Inc.|Dynamic event detection system and method|

---

CN104735106A|2013-12-20|2015-06-24|乐视网信息技术（北京）股份有限公司|Node transmission method and device|

---

US10974154B2|2013-12-20|2021-04-13|Electronic Arts Inc.|System and method for multiplayer gaming|

---

DE102014201234A1|2014-01-23|2015-07-23|Siemens Aktiengesellschaft|Method, management device and device for certificate-based authentication of communication partners in a device|

---

US20150381595A1|2014-06-30|2015-12-31|Itzhak SHOSHAN|System and method for managing multiple devices|

---

US9923907B2|2014-07-08|2018-03-20|International Business Machines Corporation|Push notifications of system events in a restricted network|

---

JP6887746B2|2015-01-19|2021-06-16|エヌ・ティ・ティ・コミュニケーションズ株式会社|Terminal management system, terminal control device, terminal management method and communication control program|

---

US9860157B2|2015-09-09|2018-01-02|Sling Media Pvt Ltd|Zero configuration approach for port forwarding cascaded routers|

---

CN105141628B|2015-09-18|2018-06-29|飞天诚信科技股份有限公司|A kind of method and device for realizing push|

---

US10209689B2|2015-09-23|2019-02-19|Honeywell International Inc.|Supervisor history service import manager|

---

KR102037999B1|2017-12-14|2019-10-29|주식회사 허브테크|Themal image surveillance system and method of amending body temperature in thermal image using radar measuring distance|

---

CN112291010B|2020-10-09|2021-10-01|中国人民武装警察部队工程大学|Multi-domain optical network traffic grooming method based on matching game|

法律状态:
2019-01-08| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2020-02-11| B15K| Others concerning applications: alteration of classification|Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 29/08 Ipc: H04L 29/12 (2006.01), H04L 29/06 (2006.01), H04L 2 |

---

2020-02-11| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-12-01| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2021-02-09| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 09/02/2021, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US32184210P| true| 2010-04-07|2010-04-07|

---

US61/321,842|2010-04-07|

---

US12/832,015|2010-07-07|

---

US12/832,015|US8341207B2|2010-04-07|2010-07-07|Apparatus and method for matching users for online sessions|

---

PCT/US2010/050068|WO2011126507A1|2010-04-07|2010-09-23|Apparatus and method for matching users for online sessions|

---